NickTR: Nice to see growing WG
<AdrianHB> nick: [talking through goals]
<AdrianHB> - Communicate progress (on a variety of specifications)
<AdrianHB> - Ensure shared understanding of roadmap for current deliverables
<AdrianHB> - Identify and prioritize new topics in scope for the next Working Group charter
<AdrianHB> - Share early adoption experience, feedback from merchants
<AdrianHB> - Determine next face-to-face meeting regions and approximate dates
NickTR: Introduce yourself to others
<AdrianHB> scribe assist: AdrianHB
<AdrianHB> ian: [getting numbers for restaurant]
<AdrianHB> ... The agenda has 4 parts
<AdrianHB> ... Part 1: Payment Request API (current and future)
<AdrianHB> ... Part 2: Payment Apps
<AdrianHB> ... Dinner then back tomorrow
<AdrianHB> ... Part 3: Payment Methods
<AdrianHB> ... Part 4: a few streams. Merchant adoption, planning for next meeting, time for any topics we must revisit etc
Marcos: We have about 99% of tests done
[Marcos walks through various implementations and how they are doing with the test suite]
Marcos: Chrome is perhaps 95%
conforming to the spec
... Firefox has implemented the API but we haven't finished the
UI yet
... We should see conforming implementations within the next 6
months, in particular at the pace the Chrome is going
... rouslan will be here later; google working hard to get to
100%
... mozilla wrote most of the tests and were testing against
our own implementation, so we are confident that once we have a
UI we will pass the tests; we are about 95% done wrt
tests
... manu has also been running the tests in the context of the
polyfill
Manu: We were able to pass a lot
of tests quickly; that was reassuring
... the only issue we had with the test suite was having to
manually run tests.
... what is the plan to automate those?
Marcos: We are trying to do that because all the browsers have different buttons, but ideally we would automate the button pushing
Mike: We have had a grand plan re testing....now we have resources invested. The plan is so you can do trusted click events
Ian: When will we exit CR?
Marcos: Could be about 6 months
AdrianHB: We have an at-risk
feature (Issue 617 about currencySystem)
... The question is whether has anybody implemented the
currency system feature?
... is anyone here interested in that use case and ensure that
this feature does not get removed?
... as a first pass, the best thing you can do is write the
test
[ISO 4217 may be updated to include some cryptocurrency codes]
[Manu...no]
<jmacwhyte> Bread here
(cryptocurrency wallet): This is something we could see a lot
of need for, but we don't know anything about organizing
testing. There are many sub-categories of cryptocurrencies that
could be used for payments. Regarding additional
currency systems...there are a lot of subcategories ....within
ethereum, for example, there are tokens
... so we could see a lot of use for ... but we are not testing
experts
Nick: Is Samsung inheriting from Chrome or doing tests separately?
Dongwoo: We are trying to do our own testing with our own UI; have not done so yet
Zkoch: Nothing to add
Molly: Nothing to add
Mike: There is a web-based runner you can run tests from; so the better way to run the tests is that we have a command-line enviornment; ping me if you want to run tests
Ian: If you have questions about testing, it's a good opportunity to talk to people this week.
<Zakim> manu, you wanted to ask if it's that difficult to implement (UI issues), and ask if polyfill will be one of the implementations in the implementation report...
Manu: Why doesn't the polyfill count as an implemention.
<AdrianHB> ian: it's not intended to be a standalone application. It's intended to be a stand-in system. As we discussed in March explicitly, our goal is native implementation in (different) browsers.
<AdrianHB> manu: we don't want a polyfill that fails the tests to go out
<AdrianHB> ian: it's helpful in the testing but I am not aware of precedent within W3C to user a polyfill as a way to exit CR.
Manu: Still not sure why polyfill doesn't count
Editor's note: Ian subsequently checked with W3C staff and was corrected: being a polyfill would not automatically disqualify an implementation from consideration as an implementation for CR exit.
Marcos: You won't be able to do
implement all features of the specification as a polyfill
... we had to add something to the browser to get this to
work.
... the iframe tests, for example, you should not be able to
polyfill the @@
... I think the expectation is that the feature has a chance to
succeed in the market
... the polyfill will inform the standard
... but I don't think it will replace the standard, nor will it
be able to achieve all the tests.
...This is an open invitation for people to help us with testing.
Marcos: Don't judge us! :)
... we are still working on the UI
... our implementation integrates well with autofill
[Marcos shows how information is recovered from previous data entry and previously stored information]
Max: Does the test suite also include the payment method manifest?
Marcos: Not yet.
Max: How about native app support?
Marcos: We currently don't have any plans
to do mobile on firefox
... just desktop
... We have a lot of interest in doing it but it's a resource
question
Max: How many volunteers have been working on test cases?
Marcos: mostly me and some help from Microsoft and Rouslan
Max: I will discuss with the payment method manifest authors whether we can add test cases for those.
AdrianHB: We are also looking at doing more test-driven editing
<scribe> ACTION: Max to look into getting resources for testing around payment method manifest
Andy: I work on Webkit at
Apple
... some background...Safari shipped ApplePay on the Web in
Sierra and iOS X...we saw some adoption and were excited to
bring it to PR API
... I wanted to show a demo of how this works.
[ApplePay button on the screen, using PR API]
[...an ApplePay sheet pops up]
[...changing address fires relevant event]
[....we show in the demo an example of an error if the merchant cannot ship to an address ...I'll say more about error handling in a bit]
[...demo shows authorization via the fingerprint]
scribe: demo shows payment
response data ]
... we use the details field to give the merchant the ApplePay
token
Andy: Merchants are interested in two events that are not yet in the standard:
a) Merchant validation. We fire an event that has a URL...merchant sends to server...who sends to our server...who responds to merchant who updates the payment quest
b) In Apple pay you can have multiple cards set up
scribe: so we added an event for this
scribe: and when you switch
between the cards, that fires an Apple Pay event
... that gives the merchant the opportunity to update the line
items...that event has information like credit v debit card
[IJ thinks there may be privacy issues to address around that one]
[Andy shows code]
scribe: The Apple Pay PMI is https://apple.com/apple-pay
... there's some data for our payment method: version,
merchantIdentifiers, merchantCapabilities, supportedNetworks,
countryCode
... there are also some optional (ApplePay-specific) fields
Andy: We have one problem ... we
redact customer information prior to authorization by the
user
... we only provide some information once user has authorized
payment in the applePay.js there
is a way to validate information to give the user a way to
correct errors and authorize
... but in PR API there is just one Promise
... merchants would have to fail the transaction and find a new
one.
NickTR: Do you currently support any payment methods other than Apple Pay?
Andy: Right now just Apple Pay
Manash: If Apple Pay extends to other payment methods....
Andy: Safari is the only webkit client authorized to use apple pay
Manash: If Apple supports payment handler API and other web-based wallets, the user experience would be different
Keyur: Will this work on mobile or desktop or both?
Andy: Works on both Mac and iOS
<mbu> The issue in question that Ian mentioned is https://github.com/w3c/payment-request/issues/645
Andy: On testing: We support web platform
tests. We run them all in
webkit...we pass all but the allowpaymentrequest feature
... there are two interesting things to note
... since we only support apple pay right now, some of the
tests we modified that use the basic card payment method (to
use apple pay)
... the second thing that we did was to automate manual tests
using some webkit internals
... to script a mock apple pay sheet
... we were able to turn manual tests into automated tests; but
not sure how generalizable those are
... would be good to understand if there are plans for
generalizable test tools
AdrianHB: In V2 one topic is
deterministic response if you specify some specific input
params
... we might want to work through that approach
NickTR: Sounds like you've discovered some features ... is your intention to propose spec text?
Andy: Yes, we'd specify on github
NickTR: Is there a payment method manifest at the end of your PMI>?
Andy: There's a web page but not a manifest file.
zkoch: PaymentMethodSelected has
a privacy issue.
... payment method detail modifiers may be another
approach
... I will be interested in hearing more about the other topics
and how to generalize them
...re: Chrome status - rolled out on Android in Sep 2016
... we went live on other platforms as of milestones 62, so
about 1 month ago
... sorry 61 for desktop
... we also have a pseudo implementation on Chrome IOS
... it's wkwebview...we inject a glorified polyfill
... but it doesn't play nicely with iframes...but we do have
some support for basic card.
... Merchant adoption has been
steady and good for us
... regarding v2 features, we will need to evolve PR API to
stay competitive
... e.g., gift codes...we should be prepared to embrace for the
next version of the API
... for Android, we also have native payment app
support...e.g., samsung pay, alipay, others
... we also have implementation of payment handler API
... there are some issues that need to be worked
through...there is a serious limiting factor in the world of
registration
... rouslan will discuss this
... as you talk about payment handlers, if we can drop that
requirement completely, that will be useful
... that's my brief update
<zkoch> I’ve got to head out, but I’m around starting tomorrow evening if people want to mee up and chat
Marcos: In order to advance on
the Recommendation Track (exiting Candidate Recommendation) we
need to do some additional things and reach consensus on some
topics
... the main thing is to have multiple implementers pass the
test suite
... the other big topic is the feature at risk.
... there are some editorial matters as well
https://github.com/w3c/payment-request/issues/480
Marcos: Nick asked us if we could
have payerGivenName and payerFamilyName
... to make it compatible with NSPersonNameComponents
Tess: Yes, we would still like
this change
... we'd rather not have to take a name and decompose
... if the merchant already has it in separate components,
could just use that
... ther is also phonetic prepresentation in some markets
... both family/given and phonetic version is valuable
Marcos: Should this be a CR change or a 1.1 feature?
Andy: Not important for CR
PROPOSED: Make 480 a next version feature
https://github.com/w3c/payment-request/issues/588
Marcos Everyone is using UUIDs. Should we make this a MUST?
Andy: We are using UUIDs
PROPOSED: Change to MUST for CR
IJ: One implication is that merchants would be required to provide UUIDs
Marcos: The proposal is that the
auto-generated ones are UUIDs, not all of them (from
merchants)
... Merchants can provide whatever they want
... we can't enforce syntax / uniqueness as the browser
Mike: How are we going to test the UUID generation?
Marcos: It's testable for length but not uniqueness.
Mike: It seems like it should be
testable
... the requirement may be the length but not the
uniqueness
https://github.com/w3c/payment-request/issues/608
Marcos: This is a hard
one....given an address...e.g., in Japan
... it may be using a non-English script
... how does the browser make the language code
determination?
... we will probably use Unicode CLDR
<shift4sms> Clarification on Unique id , it should only be unique for the merchant, so maybe it needs to be combined with the merchant identifier.
Andy: We are currently doing empty string
Marcos: What should we do?
Andy: We would happily do something specified, but don't have any current plans
Marcos: We have not yet dealt with this on the gecko side
NickTR: How do we get to an answer?
Marcos: We are kind of stuck on this; this is probably the biggest gap in the spec?
IJ: Who do you need to discuss with to get an answer?
Marcos: Implementers. Will
everyone use Unicode CLDR?
... will need to talk with our internationalization teams
NickTR: Has this been solved elsewhere in W3C?
[No]
Marcos: Given an address written in one language, you need to derive what the language is without asking the user
AdrianHB: Why?
... Why does it need to be changed?
Marcos: It's not changing it, it's just saying that's what language it's in
<jmacwhyte> I agree, specifying the language doesn't seem very important
Mike: The spec has a "language
code' property
... if we are going to require a property for PR....there are
circumstances when you won't be able to determine it....we
either decide we are not going to have it (if not
necessary)
Marcos: I need an answer from
Rouslan or Zach or the folks from Apple
... Google is using a Unicode library (that others can use as
well)
AdrianHB: I think it's ok to say "if you can't determine the language code, return nil and bytes untouched"
Andy: Also I'm curious if the user agent can determine it from the string then the merchant can do so as well
AdrianHB: We may have to return to the question of why we needed this code
NickTR: Our charter expires end
of Dec. Charter scope is important wrt the patent policy
... explicit charter language helps organizations make the
business decision to join. This is your opportunity to
call out things you want to see sharpened up in the draft charter.
... much of today's agenda will be about features, and we want
to ensure that the charter enables us to work on them. Our draft charter has us
continuing work on payment request, payment handler, payment
method manifest, payment method identifiers, and basic
card
... then we would take up formally additional payment method
specs
... such as tokenization, credit transfer, direct debit,
interledger, etc. We will also look at some operations
(e.g., how we publish payment methods, filter short
names)
... proposed to stop work on HTTP payment specs
... and some liaisons language.
NickTR: Reminder of the rechartering process: First, we get a WG
decision
... then we get W3C Management support, who then propose to the
W3C Membership
... aim to finish rechartering by March 2018 (with extension
provided by management until that time). Charter scope balance is
an art - don't want to bite off too much but want to keep the
work interesting
AdrianHB: Regarding the new
features discussion - we expect to come up with a list of
things to consider, then the chairs and staff contact will
review the scope of the charter to ensure it covers the
topics
... I don't expect it will be a list of GitHub issues in the
charter
NickTR: Our current charter excludes loyalty....question is how to open that box in the new charter, for example
AdrianHB: We have published HTTP
API and HTTP Messages as FPWD and propose to discontinue in the
next charter
... it wasn't clear who the implementers would be of an HTTP
API
... we can continue to discuss whether to drop
... but what has happened recently is that I have proposed to
the IETF WG to explore the use of our data model (payment
request data)
... with HTTP HEADERS, and I would like to mention this liaison
explicitly in the charter. My request is to have an
explicit liaison with the HTTP WG. I am presenting the
draft RFC I wrote to them next week
... what has been proposed to the HTTP WG is to take some ILP
experimentation and formalize it
<Zakim> manu, you wanted to explain why there was so little work on it. and to explain why there was so little work on the HTTP API
Manu: I'd like to give background
on why there has not been a lot work on HTTP API/Messages....we
were waiting for the PR API model to stabilize
... for HTTP Messages we wanted to create a data model that is
the same either in the browser or out of the browser...
... I fully support continuing to work on these two
specifications
... from a liaison status point of view, I don't know that it
makes sense
... I think the headers make sense at IETF
... but for the message data, it comes from W3C
... so I would like the WG to continue to work on the
deliverables....if headers cannot capture all the data, we
should do that in our WG
... we also did not focus on those specs because people were
focused on browser-based payments
NickTR: Who in this WG is also in the Web of Things WG?
[No hands]
NickTR: My sense is that the use
cases for HTTP are interesting in the case of IOT
payments
... interesting point from Manu on data model in the WG and
HTTP headers perhaps elsewhere
Ken: Why move it out of the
charter? How difficult would it be to bring it back within the
scope of the charter?
... one challenge we've seen from a Web Commerce IG perspective
is limited resources
... there may be interest but not enough resources allocated
yet
... it would be good to understand what doors we are closing if
we move forward with the proposal as-is
Ian Several reasons to remove from charter. One is patent policy. We currently have exclusions over those specs. Second, the charter is intended to reflect the groups intentions. There has been no work on these so this should reflect that.
<marcosc> mc: you would need to incubate it regardless
<AdrianHB> ... can any group take up the work and continue to work on it?
<AdrianHB> ... yes, I think there is a need for the group to charter such that it is in.
MattSaxon: We would like to continue to work on HTTP-based payments. Can we have it as "possibly in scope" in the charter?
dezell: I would like us to keep the HTTP payments in scope for this WG
<Zakim> manu, you wanted to say patent policy for data model is already covered with Payment Request API and to say we might want to be hesitant to take it out without someone else
manu: What Ian said re: HTTP API
makes sense. The data model is already in PR API
... it's really the documentation of the data model we have in
the browser....so we could do that in the wG, and push HTTP
Headers off to the IETF
... I think that's a reasonable way to keep things in scope
Ken: If we retire it and bring it back...what is the level of effort of patent analysis later?
Marcos: For those who are
interested you can incubate it in CG
... to get something that people can work on
NickTR: I've heard several
participants say they are interested in leaving in the
charter
... Does anybody want to speak strongly in favor of taking it
out?
AdrianHB: I don't want to strongly say take it out, but I do want to say "if you want to work on it, make a commitment to work on it."
MattSaxon: I'm searching for a
pragmatic solution. The difficulty I would have is working on
other items today.
... I can't make a commitment of when I will work on it.
Manu: Concrete proposal is to
leave the data model spec in the group and discontinue the HTTP
API spec
... people have not been working on the HTTP API
... I am happy to take the PR API Proposed Recommendation and put data in a data
model spec.
AdrianHB: But who is going to
implement the specs? And how will it improve interop?
... I think we need to show that there's an interoperability
need that this would meet and there are people lined up to
implement it.
... The IETF use case require neither this data model nor the
HTTP API
PROPOSED: Leave data model spec in the group and publish the HTTP API as a Note in the WG
Marcos: You can transfer the spec
to a CG
... e.g., to the WICG
<AdrianHB> +1
IJ: Beyond the charter, there is a social expectation that we need stakeholders to sign up to work on this before we start working on it
[Show of hands for people interested in general in a non-interactive payment request specification]
(Half the room-ish)
PROPOSED: Leave data model spec in the group with an expectation that we will need people to step up as interested stakeholders to move this to active work. Publish HTTP API as a Group Note.
NickTR: Indicate your support of proposal in IRC
<manu> +1
<Magda> +1
<AdrianHB> +1
<bertrand> +1
<Ken> +1
<MANASH_MC> +1
<marcosc> +1
<CyrilV> 0
<mattdeganon> +1
<cwebber2> +1
<alyver> +1
<frank> 0
<marconi> +1
<MattSaxon> +1
<vincentK> 0
<dezell> +1
<Sachin_ahuja> +1
<dlongley_> +1
<oyiptong> +1
<joerg> +1
<Keyur> +1
<mdadas> +1
<mountie> 0
SO RESOLVED
[Adrian walks through his slides, which summarize issues involving feature requests]
AdrianHB: We've postponed some
features over the past couple of years
... today we are going to review those and other suggestions
for what to do next in the API
... today we are going to get a feel for what we need to work
on. I have created some themes
[Slide 2: Themes]
Adrian: I organized topics from least to most controversial
[Slide 3: Best Practice]
AdrianHB: Not sure if deterministic testing should be part of charter.
IJ: Issue 613 is about merchants
testing their use of the API (not browsers testing their own
implementations). I could have a higher-level
topic like "Merchant Adoption" that could include topics like
testing by merchants
... as well as things like developer portal etc
Marcos: I'd support exploring merchant testing further
Molly: +1 to supporting something like this
Steve: As a developer I think
it's a great idea.
... this might affect multiple specs
... I think you will need to propagate information test results
through various specs
Adrian: Issue 600: We also want to align with feature policy as that advances
[API and Data models, slide 4]
Adrian: Multi-currency...merchant
wants to be able to say $100 or 90 Euros
... slightly more complex way to do this is per-payment-method
amounts
... for example, for each accepted payment method, I could
specify different currencies and amounts
AdrianHB: In my experience with
push payments, this is usful
... merchant wants to advertise different produces per payment
method
Manu: I think that these issues
are a signal for a deeper concern that Digital Bazaar has about
payment request API; see my blog post about
monolithic design of PaymentRequest API. Recall that we had asked
that Payment Request API be more composable. I think some of
these issues that you are referring to hint that there will be
a growing set of features that the browsers will have to
implement.
... the concern that we have is that payment request API will
take on more and more features, which will give merchants fewer
and fewer options.
... the general comment is to address this in a healthier way,
and to deal with a more general problem
... I think that we should continue to keep that in mind as we
work on the problem.
... I think we have painted ourselves into a corner and that
the design doesn't lend itself to extensions. My hope is that if we
implement some of these new features, we find a generalizable
way to do this, so that other WGs can reuse components
... e.g., related to billing addresses
... so do we slap everything into Payment Request or do we
create a smaller API that we work on in the rechartering,.
manash: I agree with Manu's point
that we don't want things to get too complicated. But I come at
this problem from the merchant adoption angle.
... we need to see whether we are addressing valid merchant use
cases. If we see that these
features are important to merchants for their adoption, then we
should elevate the priority of these features
cwebber2: I work on decentralized
social networks. That work ties into payment request API. The
type of technology that is being developed here could be
generalized even beyond payments.
... We recently came up with an identical work flow in our
other group for a non-payment use case
... maybe there is an opportunity to be less specific to
payments
mountie: multi-currency is an
important requirement
... this is especially important for non USD economies
adrianhb: I am hearing 2
discussions (multi-currency, composablity)...I would like to
return to composability at the end
... I am hearing multi-currency as an important issue
AdrianHB: I also think that billing address is a big demand
... that we need to capture not just shipping address but also
billing address
IJ: Billing address is currently in Basic Card. Are there other payment methods that need it?
Andy: Apple Pay does need billing address
<manu> Ian: One way to think about this is if these things are specific or generalizable.
NickTR: I expect we will need for tokenized card
AdrianHB: So I am hearing strong support for billing address as a top-level feature
Issue 639 - update paymentrequest fields before calling show()
scribe: two things happening in
parallel...as a merchant I am looking at information in the
background and the user clicks show before I am done
... the question is what to do (e.g., NOT show out-of-date
data)
... so it sounds like there are refinements to the API (e.g.,
passing a promise to show) to fulfill this use case
<jenan> adrian is summarizing https://github.com/w3c/payment-request/issues/645 but 639 is related
Marcos: 592 is about "get" on current details of Payment Request
AdrianHB: also think we need to look at validation and errors passed to the payment sheet (issues 225 and 537)
[API Flow and Extensibility, slide 5]
Adrian: Some issues related to
payment handler - handling abort() in the payment handler
(issue 473)
... capability matching (issue 470) and where do we need more
extensibility?
AdrianHB: Another requirement
that has come up is the ability to pre-filter shipping
addresses
... e.g., "only allow shipping addresses within a particular
region"
... Apple Pay does this by giving merchant some info about the
shipping address (but not all) and allowing merchant to send
back information to the user side
... Issue 548 is about capturing additional data (which is
related to the composability topic)
[Business Requirements slide 6]
Adrian: We don't currently
support pre-auth today
... that could be part of canMakePayment() where an app could
do a pre-auth for that payment method
... two topics were about origin and authenticity of data; I
think we should make an explicit decision whether to
explore
... do we want a generalized feature to allow parties to
identify one another
... Do we need to deal with regulatory requirements related to
proof of consent to pay (issue 113)
<npdoty> Does TLS not provide the level of assurance you expect about integrity?
<voisine> for push payments, the payee may need to supply refund information
Adrian: these are becoming more
specific in Europe.
... we need to be sure that what we spec out can be used in
different regulatory environments
... are we doing things to enable / make things
difficult.
... Do we want to enable the merchant that explicitly tells the
user what they are paying for? Is there a regulatory
requirement?
... my feeling is that as soon as we cross the line where the
browser is in the regulatory space, it becomes more
complex
... e.g., what liability might the user agenda bear?
<Zakim> manu, you wanted to note that many of these are potentially Verifiable Credential use cases.
Manu: You could argue that
pre-auth and digital signatures are closely related to
verifiable claims work
... so if we work on that, we should have a liaison
Adrian: I think it depends on
what you mean...but I hear you
... agree we should add VCWG to our list of liaisons
jheuer: We are putting a lot of
semantics into what we do. This means that we need to
understand the semantics implications in different
contexts
... mechanisms should remain neutral as possible regarding
regulatory semantics
mountie: Regarding proof of user
consent to pay.
... if we are trying to handle this, we will need to discuss
lots of things like non-repudiation
Adrian: Store pickup.
Adrian: Suggest as out of scope "manipulation of available
instruments by browser, based on heuristics" (issue 237)
... I don't think we need to spec that one out
... eg., should a browser stop presenting a card if the card
continues to fail
IJ: +1 to not calling that out explicitly
AdrianHB: I suggest we close it
and leave it as a a browser implementation detail
... Do we want too spec this? Do we want force browsers to show
all payment methods? My preference would be that the scope of
the charter not touch on this
<manu> +1 to put manipulation of available instruments by browser based on heuristics out of scope (because of the can of worms that opens up)
nicktr: Strong +1 to leaving it out
<MattSaxon> +1
<mountie> +1
<Magda> +1 to leaving it out
<mattdeganon> +1
<rouslan> +1
<dezell> +1 to leaving out
<scribe> ACTION: AcrianHB to close issue 237 with "will not do; leave to browsers"
alyver: I wanted to start by
voicing our support for some of the topics before lunch:
billing address collection, multi-currency, and in-store
pickup
... for discount codes, we opened an issue (Issue 145) that was parked; that was fine for v1.
... 80% of our merchants use discount codes. 20-25% of
transactions involve discount codes
... so we'd like a form in the sheet, e.g., alphanumeric up to
a certain number of characters without browser validation
Marcos: What do users do?
alyver: Having the user input data to a sheet creates friction. We have worked around this today by having a pre-sheet that pops up
marcos: We'd like to work on
that, but want to see more of what they look like in
practice.
... this way we can help users enter them
alyver: codes are typically words (or like "fall2017")
adrianhb: I think that giving
users a free input field is not a big issue in itself, but
giving the developer the ability to label the field may be more
important.
... but there are security issues like if the label says "Card
PIN"
JamesM: Another issue has to do with merchant-side validation of codes...including price updates
AdrianHB: That's a good question
JamesM: My first impression is that it would be handled BEFORE PR API is called
Sachin: It belongs in the merchant realm, I agree
alyver: This has probably been
the biggest issue we've faced to implementing PR API
... this issue and adoption by more payment handlers would be a
significant boost
... we have everything we need except discount codes
rouslan: I think it would be a
great idea to add discount codes; I'm not sure yet how it would
be handled in the UX or payment apps, etc.
... definitely I think we should do this in v2
Magda: Point of clarification - are we talking only about promotional codes? Or also coupons and other offers?
alyver: For us so far it's only been promotional codes
keyur: Discount codes belong to
the merchant; there could be multiple codes. The user needs to
know that the price changes with the discount code.
... before even invoking PR API the merchant could validate the
code and update the amount then update the amount; I think that
will be a better user experience
alyver: That's what we do today;
I'd rather have it all happen in one sheet
... with an event/update cycle
marcos: Let's capture the use
cases in github
... I am supportive of the model proposed - put in code;
merchant validates; then it can be added as a display
item
... I think there are good solutions there
... that gets us closer to display item times (e.g., tax v.
discount code v. generic item)
Jenan: Stripe checkout is in some
senses a PR API precursor. The #1 feature people ask for is
discount codes
... I think next logical step is adding discount codes;
merchants don't want to split the user experience
... +1 to alyver's point of having PR API take this on; we've
had this request for years
... the earlier in the flow you put PR API, the better the
user experience
... if you jump straight to the project page, the more value
there is to PR API
Manu: Checkout is a complex
process; we can't put everything in the sheet.
... another approach is chattier merchant interaction with
user
... would multiple APIs enable achievement of goals, or is
really all needed to be in the browser.
Ian: Regarding what to say in the charter: I am hearing a lot of support for discount codes being in scope. There may be other topics (e.g., coupons) but I don't want to prematurely generalize. I am hearing specifically support for discount codes (which I believe have less information than coupons). I don't think the charter needs to go into detail about how we solve the use case. Regarding API composability, please suggest concrete proposals (e.g., for multiple APIs). This is what we did when we first started, and we picked an API approach. It is trust that we have more experience at this point, and it's fine to entertain a new proposal. But let's be concrete.
Manu: There's no purpose in putting forward a proposal if there's no appetite
Ian: I think we can only make a decision given a concrete proposal.
Adrian: Shipping address
involves the REUSE of stored data; discount code does not.
... that makes me wonder whether the purpose of decomposing the
API is for the merchant who doesn't want to use shipping
address via PR API, or is the purpose to have more flexibility
in the call?
... I think the latter will be a difficult solution to
propose. I think that it will be
hard to sell a generic sheet-building API
<mountie> discount code => two different amounts => multiple currencies and amount? connected
alyver: I think Manu raises an important point...other features that are missing from our viewpoint:
scribe: or accepting terms and
conditions on checkout, or shipping dates (e.g., for
florists)
... these are things that are collected on checkout
dezell: The need for an API has
become apparent in the Commerce IG....there's a lot of
computation that becomes predictable...but outside PCI concerns
for payments
... in the 80%/20% rule...I am hearing most people want
promotional code
... it's not as complicated as "offers generally"; I don't see
harm in adding that.
rouslan: Thanks Manu for pushing
us on this; I do think we should do discount codes. Regarding
reusability of discount codes; perhaps payment apps should
handle discount codes
... you collect them (and store them) and reuse them at a later
time
... how this would work in terms of UX is not yet clear to
me.
... if there is no good way to do discount codes, we may end up
not doing them
marcos: I echo Rouslan's
point.
... making things generic has to also be driven by the
particular use cases
... Manu's raised some interesting ones.
... there is a risk of overgeneralizing. I am not for a generic
checkout API.
... we should be looking into limiting the API rather than
growing it. If we are adding more UI, we may want to have it be
handled by the Web itself
... let's look at what people need to do and find solutions to
those.
jheuer: Discount codes can be
reused in some cases.
... I think we are over-simplifying and ultimately making the
API overly complex
... I want a tool that allows me to bring in a token, and not
rely on the browser to understand meaning
<jyrossi> +1 on Jörg's demand "I want a tool that allows me to bring in a token"
NickTR: I am hearing there is an
appetite for discussion about discount codes; so we should
ensure that the charter enables that.
... I think we need to keep an eye on composability.
andy: I have four topics that
came up during our implementation of PR API in Webkit
... The first topic is the need to dispatch custom events for
apple pay
... one for merchant validation, and one for when instrument
changes (e.g., from debit to credit)
... I have heard we may be able to use paymentDetailsModifiers,
and the more I think about that the more it seems
reasonable. I mention custom events not
because we need necessarily these specific events, but rather
how does a payment method deal with custom events.
... we created applePay- namespace prefix for our events
... we tried to dispatch these events on data...but the spec
has wording on JSON serialization that makes it difficult
... is this an issue that has been raised previously?
... any suggestions for new payment methods that dispatch to
the merchant?
AdrianHB: I think there are two
things there since Apple Pay is a payment method
... first is whether there should be a payment method change
event ....and what scope?
... I think the payment method modifiers works but can get
complex
... so interesting to understand whether an event is fired when
there's been a change in user selection of payment method...but
the question is also whether payment apps should be able to
send back signals
Marcos: I would encourage you not
to prefix with applePay-.
... eventually all browsers will need to implement those
prefixes.
... you could fire events and not have the corresponding IDL
events
Andy: this one is pretty specific to Apple Pay
Marcos: I suggest
addEventListener as a fallback.
... just avoid the prefix
... the lager question is about custom events
... I agree it will come up and is reasonable to try to sort it
out
rouslan: Thanks Apple for getting
more involved! I'd like to echo Marcos' point about avoiding
prefixes
... I see two possible solutions here.
... one solution is maybe for generic reasons for these events
and every browser would implement them....web devs would not
have to write custom code
... a second way I see this working is similar to service
workers...where new APIs that need to be in the SW write
extensions to the SW interface
... you write an extension (e.g., with two extra events)
... web developers would feature check for those event
endpoints
... they would not be prefixed (ApplePay-...)
... but I think I am currently more in favor defining generic
events
... I think it would be even ok to include this in V1
andy: The only one we need in v1 is validate
michelle: It's interesting that
you mention that. We have fired a request with PR API because
there is no way to update things after show()
... merchants may be making computations on server and need to
do updates after show()
andy: I have heard that use case
as well.
... Maybe one problem with that is that it's still
"race-y"
... it extends the time you have to get data back but does not
give you an async way to do it
michelle: If it worked like shipping that would suffice for us
AdrianHB: We've ended up with 2
models updating the sheet depending on what changes
... in some cases modifiers, in others events
... should we move to a standard model ?
... if you change anything on the sheet we fire an event
... and we always redact some fields
... if I were developing against that it would seem a lot
easier
... I would know that whatever field changes I can get an event
that I respond to
NickTR: I am hearing there is work to do around the event model
Jenan: I am curious about plans v. canMakePayments() v canMakePayments with active card
Andy: We are still discussing this; today it's implemented one way but that's not a final decision
Marcos: Something here seems specific to a system that has a validated merchant
AdrianHB: You raise an
interesting point..if we do merchant validation, we can unlock
features that we've resisted before due to privacy
concerns
... e.g.,having validated a merchant, I can fire events that I
would not fire otherwise
... Is there interest in merchant validation a la Apple
Pay?
<alyver> +1
<shift4sms> +1
<MaheshK> +1 on exploring merchant validation
[Only a small number of hands raised for merchant validation]
NickTR: There's a difference I think between supporting something in the ecosystem v. adding something to the ecosystem
AdrianHB: Any OPPOSITION to merchant validation solutions?
NickTR: I might strongly oppose; I have to think about it
[We see a demo by Andy of how error reporting could work]
Andy: Error reporting is the next feature request
Andy: So merchant can guide user to edit and fix errors
Andy: in our implementation you can send multiple things through the API
Adrian: I am hearing some interest regarding error messages
Rouslan: Seems like a v2 feature
Andy: ApplePay allows specification of a default shipping and billing address
Andy: Goal is to allow merchant to specify the address in the constructor
Marcos: +1
andy: Another feature is address
validation
... Contact info is redacted until user authorizes
payment
... some validation cannot be performed during changes
... full contact info is available after accept promise
resolution only provide, but no change for error
correction
... apple pay js solves this with the validate merchant
event
... could potentially solve with an extra, non-redacted
shippingAddressCHange event before accept promise
resolution
... that would allow error correction of shipping address
(though not billing address)
... so we can't easily retry
AdrianHB: Part of the problem
with PR API show() you don't know whether money has left
account.
... we may need a slightly different flow
... this seems like a big change
shift4sms: +1
... the payment address...I can see some cases where the
merchant won't ship to a PO box...how does that work if street
address is masked
Andy: In that case we have a status of "address unserviceable"
AdrianHB: Ability to do "last
opportunity validate" might be interesting, but also raises
privacy issues.
... this is where merchant validation is interesting....allows
for more trust
oyiptong: I am in favor of
continuing to explore this.
... knowing the billing address is important to us...the origin
of the payer determines fees and other info we might add to
line items
... there are some regulatory issues for us as well (e.g., if
payer is based in US, they have to pay in USD and not another
currency)
... for these we need to know billing address country before
authorizing payment
<Zakim> rouslan, you wanted to say this may be done by adding a new method on the PaymentResponse object.
rouslan: Regarding "best way to
structure the API to do last-minute validation...."
... I think a good way to do this could be a new method on the
response object....e.g., response.tryAgain()
... with information about what field caused charge to
fail.
... that would keep the sheet up (since not payment.complete())
and improve user experience.
AdrianHB: But push payments will
make this tricky (since payments are already done)
... so another thought is an event back from payment handler to
merchant
Andy: I will raise issues for all these four points
Jenan: We filed two issues - user
wants to update line items before show().
... because canMakePayment() won't be affected, we can just
make a new payment request...which is what we are doing, so
that's done
... but the related issue is that merchant sends request to
server and user clicks Pay before I have response bakc
... so the idea is to show() but e.g., don't allow the user to
finish because I'm still waiting for data back.
... so need async way to finalize total, line items
... e.g., show() takes a promise
... or some other way to tell the browser "user wants to start
payment but we don't have have full information"
<Zakim> rouslan, you wanted to say that payment handler can set the "retryable" flag. and to
rouslan: Interesting use case;
that's for raising it
... I can see how modifiers don't work here
... so could show the sheet and have button grayed out
... do you want anything else to appear in the sheet, or is it
just a generic loading screen
... and maybe times out after a minute
... but if you want to show other things on the sheet and not
the total price, then it's more complicated
Jenan: For this purpose, the
loading screen would suffice
... ApplePay's onPaymentSElected behaves similarly
... we don't expect the delay to be long
... so sheet comes up...promise resolves, and move on
Rouslan: I'd like to discuss with other browser vendors as well
Jenan: The last issue is billing address
AdrianHB: I am hearing strong support for billing address
AdrianHB: Do you see a path forward?
Manu: Depends on the browser makers.
Marcos: We don't see this as an
issue.
... I think that we might see this as an emergent
frustration
... or people might want back form data rather than JSON
string
... these issues may bubble up naturally; I don't think we need
to change the API a priori, I think we could decompose what we
already have into what we need
... I think it's premature to do it now
... the market needs to tell us what we need based on use
cases
AdrianHB: At the moment, there is no other API to gather that stuff. If verifiable claims were implemented as an API.....
rouslan: I can see both your
points....
... I see the value of having pieces that work by themselves,
but I agree with Marcos that we need more players on the
platform to tell us what problems they encounter and their pain
points....
... I agree we don't want to make the API a kitchen sink;
suggest we follow Marcos' suggestion
AdrianHB: Should we support split tender now (e.g., when using gift cards)?
[8 or so people expressed support for split tender payments as an in-scope topic.]
nicktr: We talked about compatability ... is there a way to get architecturally and ensure backwards compability
Manu: I don't want us to get into
a position where we say "this doesn't exist so we can't do
it"
... I like Adrian's criterion of whether a piece of data is
reusable.
AdrianHB: I think that the charter could say something about web extensibility in the charter
MattSaxon: We've just sat through various feature ideas....big bucket of stuff to work on...how the WG prioritize them in a continuous way?
Marcos: We can tie in the issue of versioning
NickTR: let's revisit that
tomorrow
... good question especially as the group has grown
Evgeny: We now have PR API and Payment Handler with "basic-card" and "other payment methods" (url-based payment-method definition), but I suppose it is not enough to have payment method single-dimensional. Say, for Yandex.Money payments (which in proposed scheme should now be a payment method itself) there can be a wallet payments (which can be done only in Yandex.Money interface) and card payments, which should preferable be done in a native browser interface. And now there is no real way to made Yandex.Money card payments in a process with more than one payment method enabled in native browser interface since there is only payment-method field in API. I'm not sure where should it come to Charter or just to Issues.
MattSaxon: The general idea is
that payment apps should be able to ask for information from
the environment
... I have a use case related to this as well
Rouslan: Payment Handler is in
Chrome Canary (behind a flag)
... it currently works on chrome desktop and android (slightly
better on Android)
... the way you flip a flag is
chrome://flags/#service-worker-payment-apps
... Check out our demo at bobpay.xyz. There are ways to
register or unregister the payment app (service worker)
... we get name, icons from Web App Manifest
... on Android we are currently just displaying the top-level
name of the app
... we might experiment more on desktop with showing more
details of the instruments registered within a payment
handler
... payment app registration happens with
installPaymentApp()
... the registration process returns a payment manager which
tells the browser what the available instruments are
... each instrument has the name of the payment method (e.g.,
basic card or custom PMIs)
... you can also specify name/icon per instrument but it may
not be shown by the browser
... we register a service worker (paymentapp.js)
... the main thing that goes there is an event listener for
paymentrequest
... note that the handler "payment request" is not an exact copy
of the merchant's payment request; it's a subset of that
data
... the event is fired when the user selects a payment
app
... payment apps can do a variety of things in the event
handler
... for example, simply return a token
... but you can also do asynchronous actions, such as a round
trip to the server
... this is accomplished via promises
... and perhaps one of the most powerful features is to open a
new window for user interaction
... e.g., to have user confirm a transaction or use some other
api (e.g., web auth) to get strong auth
... all this happens inside the promise
... remember that the url that you open (for the window) has to
come from the same origin as the payment app itself
[Masterpass part of demo]
Manash: Masterpass is a network
of wallets
... merchants implement the masterpass API....we have our own
wallet but also are implementation of capital one wallet, Bank of America,
CityiPay
... if the merchant indicates that they accept masterpass as a
custom-payment method, then we would expect any of our wallets
to appear if registered.
... Web-based wallets are important to us. Most of our users
use Masterpass in Web wallet form
... we are REALLY interested in Payment Handler API as a
result
... to register a payment app, the user has to visit the domain
of the payment app
... in the demo I register masterpass as a service worker and
then the bank app as a service worker.
... now when I click Pay the sheet pops up with a payment
handler.
... it will be interesting to see how the open window
experience happens
... and interoperably
... now that we are in the masterpass wallet, you could
authenticate the user, allow user to add/edit instruments, and
so forth
... then when the user clicks pay, the data goes back through
PR API
... in our demo today we return an "id" (specific to
masterpass)
... but in the future we want that to be tokens
... [Manash shows selection of either wallet through the chrome
sheet]
... installation could be silent or with user consent
... but the user has to be in the domain to get the service
worker registered
... Here is what we would like from the browsers:
rouslan: For Chrome, we plan to
make data available across Chrome browser instances.
... on Android this is possible with native payment apps
... where any browser can communicate with any payment app (but
just on Android)
... I would like to solicit feedback from other browsers.
... whether they would be interested in implementing Android's
API allowing them to use payment applications on Android
... currently I am aware of two payment apps that have launched
with this...one is Google's payment app in India, and the other
is Samsung Pay
... and so if browser vendors implemented the Android API,
those browsers would work out of the box
AdrianHB: One worry in terms of rolling this out beyond Chrome and possibly Mozilla is the dependency on service workers
<nicktr> google's payment app in India is called Tez
Ian: One implementation update regarding service workers: it is my understanding that service worker implementations are underway in Edge and Webkit.
jenan: What are browsers planning
for UI in desktop
... will it be as nice as the sheet itself?
rouslan: We definitely want the
UI to look premium and safe and recognizable
... we will be improving on the demo you saw today. We also need to work
with the security team so that either the origin or other info
is available for trust
... as a first step we have been thinking of using the same
window and making it the same size of the payment sheet
... we will have to do a bunch of A/B testing to ensure that
the conversion rates stay up
<nicktr> Ian: do you want UI review volunteers from this group?
<nicktr> Rouslan: Would be great to get quick review of UIs
rouslan: ..but user data will be final judge
<manu> scribe: manu
Ian: Recap - payment apps task
force in WG - brought Payment Handler to its current state...
we moved payment apps into main WG.
... We haven't done much recently, focused on getting to TPAC
and getting ready. This is the first time we're really getting
feedback on spec so we can move forward on these issues.
... We're adjusting API based on real world implementation
experience... features in spec have been implemented... there
have been improvements and refinements... it's being
implemented.
... We created the resources "payment app good practice" as a part of the
development portal.
... We've added a number of Payment Handler API editors (Rouslan and Jinho), Marcos will join us once
he's done w/ test suite.
Ian: First issue... capability matching... at a high level,
payment request API matches on payment methods. What does the
merchant accept?
... Filters give you extra granularity.
... Merchants can provide finer detail to improve user
experience... only W3C payment methods have capability matching right
now...
... An issue that has come up - who does the actual matching?
If the browser does it, you get the benefit of the browser
shielding data from merchant and making life easier for payment apps... but browsers have said they
don't want to do capability matching... why not have payment
apps do it?
... Payment apps could do it, via boolean matching... challenge
- can make payment is the key place where this happens... if
something happens before user has selected app, there is a
privacy issue. We have a concrete proposal from Rouslan...
standardized payment method would provide static capability
information.
... Browser would do the matching and there would not be any
data leaked to the merchant.
... For URL-based methods, canMakePaymentEvent provides data...
if merchant already has information - merchant can accept the
risk if they know relationship... risk is mitigated.
... There is an edge case where payment handler supports both
types, standard and URL-based one. Favor privacy over
completeness... match may happen on static data in that
case.
... Is this edge case going to arise? Is that a common
scenario/practice?
Sachin: Can we make it such that the response on canMake... finer grained... merchant can prioritize based on their economics.
AdrianHB: Unfortunately, I think that'll have issues w/ privacy. Merchants shouldn't be able to probe the API.
Sachin: Yes, fingerprinting problem... but is there any way to ensure privacy...
Ian: You can query with just the payment method 'Masterpass'... nothing else.
Sachin: Yes, but that's a hack that gets around it.
AdrianHB: There are hacks around it, but only if user has previously consented to Masterpass
Sachin: Personal information shouldn't be shared... just list of accepted payment methods w/ yes/no.
rouslan: Thanks for describing
the filtering, here's the latest thinking.
... If the merchant requests basic card and URL-based method,
and payment app supports both basic cards and android.com/pay -
what we were considering doing... browser looks at basic card
instruments, filters those out, and shows payment app if it's
possible to pay, doesn't show it otherwise...
... however, it may be more logical to perform steps as
before... we see that both merchant and app supports
androind.com/pay (for example), and just for that one URL-based
payment method, and fire that one event and that event would
carry that information. In that case, we're still respecting
relationship w/ payment app and merchant, but not violate
privacy. Our thinking is evolving.
<Zakim> rouslan, you wanted to talk about the edge case
Manash: A couple of quick questions related to filtering, is there a way for the merchant to indicate that they have a preference. Can the merchant ask for custom payment methods, but say they have a preference for certain things?
Ian: The API is silent on that right now
Manash: There is a ranking - for basic card, for network tokens, for custom payment method - what are the browser vendor's vision for this?
<MaheshK> rouslan: can you provide link where the proposal is for this event you talked about for canMakePayment?
NickTR: The spec didn't use to be silent on ordering, but we took that feature out.
marcosc: It talk about user preference
adrianHB: But not about merchant preference.
Ian: Delegating abort() to Payment Handlers... how do we forward merchant desire to cancel on to payment request?
<rouslan> MaheshK: Pull request: https://github.com/w3c/payment-handler/pull/170/files. Preview: https://rsolomakhin.github.io/payment-handler/#filtering-of-payment-instruments
Ian: Just because merchant
recceives it, doesn't mean it can be canceled.
... We have no expectation for payments already sent to be
rolled back
... abort() delegation via an AbortPaymentEvent...
... PH can respond w/ boolean indicating whthere it was able to
abort payment.
Ian: Display order of payment handlers - there are a few options on the table:
Ian:... You could say nothing, or use user-side order prefs... allow user to config display order... or some combination
<keyur> +1 for option 2
Ian: I don't have a sense from browsers today on their preference.
Manash: Now that we're looking at security... what security mechanisms are browsers going to use to show default payment... just putting it out there.
Yvgeny: It's impossible to clearly decide order from browser side... might also need info from merchant... "must favor" is the most strict sentence that can appear.
Yvgeny: It can't purely be a browser decision.
mattdeganon: This is an area where this seems strange where we allow the user to set preference but instead create an arbitrary order based on the browser... from a personal and an issuer standpoint... we may run into issues if we try to arbitrarte that.
Ian: Is this regulatory trouble?
mattdeganon: I heard an issue
earlier today - if we remove or drop priority of a payment
method, a decline issue can come up for any number of reasons
but we don't know if user has declined using the payment
method.
... if the browser removed the choice, that may have been the
wrong choice.
dezell: We've been around the
block on this - let's stay silent on this... merchants
frequently have contractual obligations w/ card brands -
merchant has skin in the game to have some say so. This is
fraught. This will probably cause us more discussion than what
we choose to have.
... In brick and mortar stores, when people buy terminals,
payment choices need to be shown in a precertified way. I don't
think we need to go there, but we don't need to forget about
it.
Keyur: There is a fourth options - last used payment method... rest can be up to browsers implementation method... last used should be first option, then users choices.
????: Strongly endorse option 3 - we do it all over the place - our electronic life is fraught w/ acting on behalf of the user
Marcos: we should say nothing
Etienne: merchants have a hard time following selection criteria... regulatory issues, in france, if ordering isn't defined, it's a bit of a dead issue... don't know if it'll stay like that in the long run. They are specfic on how co branded cards are displayed,... food for thought.
Ian: What do browser vendors think about making this configurable
marcosc: Nope, don't do it.
rouslan: I second that
molly: Nothing to add.
Manash: +1 to Marcos
Tess: It's probably best if specs are free from requring specific UI stuff.
Ian: Clearly, tension in the room on various mechanisms forward..
nicktr: as we get more implementations, different jurisdictions will have different requirements - spec will need to support all of that.
Joerg: I'm a bit surprised to see
this discussion going this way, if this is the user's agent,
they should have a say in these things.
... Maybe it's a wallet that does that? There is a place for
innovation here...
... I could have context information that helps the user pick
the right thing... take the viewpoint of the user - this should
be open in a way.
Ian: Thanks for the input.
Ian: Issue 123 is about payment handler being able to access user-stored data to speed up payment handler onboarding. Issue 218 is about browser having access to payment handler data to speed up user onboarding.
Ian: Browser/Handler Data Exchange... if browser stores some
data, some folks want access to shipping address... could you
have payment app request it if you have user consent.
... This would be new... payment app and browser to get stored
data...
Frank: We thought about how we
would implement this...
... We thought about how we should implement this...
Keyur: Regarding shipping address handling ...
Ian: This is payment app getting
shipping address...
... This could be useful for initial capture of data if user
doesn't have data yet.
Frank: This is only if user has info in the browser.
NickTR: This is like AVS for push payments, which you can only do if payment handler gets info from browser.
Sachin: This is another case of checkout and not payments...
NickTR: risk information on the
transaction, so payments.
... Is this on payment registration or per payment?
Frank: Per payment.
Michelle: We find issue 218
useful - payer email, payer name, payer address...
... In chrome, address comes after payer info...
<mbu> slight correction: in chrome, payer info comes after payment handler selection
Ian: Merchant Interactions with
Payment Apps - basic card - given merchant might not want
payments from particular payment handler - two use cases cited,
payment app is known to be fraudulent or it's a
competitor.
... Other concerns - would like to have partnerships w/ payment
apps - favor them... might want to learn about user's payment
app for given transaction... contributing chargebacks to given
payment handler...
... I don't think that current expectation would return
information - payment handler chosen... just get data back...
few ideas w/ helpingn w/ merchant side filtering... merchant
can creat etheir own payment method... Target publishes Target
method via payment app manifest -f eels heavyweight, but can be
done today.
... Or we could augment w/ accepted handlers that parallels
manifest from merchant perspective... payment handler
information can be identified... maybe merchant should have
mechanism to say "these are the things we accept"... browser
algorithm could look to see if user has matching apps... then
shrink that set by removing stuff that merchant doesn't
accept.
Steve: So, you're treating that like a whitelist instead of a blacklist.
Ian: We haven't gone that far
yet into deciding whether whitelist or blacklist or both, etc.
... Any other observations on whitelist?
<sachinahuja> +1 on whitelist
NickTR: That's in the payment request?
Ian: The "manifest on the merchant site" didn't come up...
NickTR: There are a set of origins that merchants accept credentials on...
AdrianHB: I'm not sure this requirement is justified - if merchant doesn't like a particular payment method, they shouldn't support that payment method.
NickTR: This is a requirement for me...
AdrianHB: A card number is a card number - doesn't matter where it comes from.
Ian: You can't ignore the desire to prevent competitors from gathering data on your mechanism.
<oyiptong> +1 on whitelist
Jenan: Strongest use case for this is basic card - saying to merchants, if you want that power, you don't want everyone to get that info... seems like semantics, but sounds like something we want to discuss.
<mbu> +1 on allow whitelist as well
Jenan: For merchants that want to
do this, on behalf of... like Stripe...
... Why do you have to say it's all or nothing, why can't it be
an extension to Basic Card
AdrianHB: That would be a new payment method.
Jenan: I'm ambivalent about it becoming a payment method...
adrianHB: You want to forward this payment request to different payment requests...
Jenan: Like known bad
sites.
... If any site can install payment handlers... we have
responsibility to protect both merchants and users from known
bad sites.
AdrianHB: What's the risk here? Getting bad card data?
Jenan: Risk to merchant and their reputation if a bad payment handler scoops up bad stuff and sends it back.
[Jenan explains the risk to AdrianHB, who agrees with the risk... don't know what 3rd party is entering information.]
NickTR: This is the risk of bad payment handlers.
Jenan: What if they sell card numbers?
AdrianHB: The merchant has no say on what payment handlers to use...
Jenan: There is no permissions dialog that pops up...
Marcosc: No, there is.
rouslan: Payment Handlers in chrome support basic card.
Manash: Yes.
[Manash outlines how this is supported now.]
Jenan: One solution to this
problem is merchants or payment processors have many other
solutions - my fear is not having that, not having visibility
with ease of installing... the combination is dangerous.
... It'll probably be easier to have user permission - stripe
is in position to manage block lists - another thing to
manage... don't have a strong opinion.
Ken: A couple of things...
... Big fan of sharing perspectives... it's helpful to achieve
a balanced and optimal solution... with that said.
... I hear the concerns that Jenan has raised, at AmEx we hear
that from merchants as well. We're trying to navigate this. I
sit on AmEx network side of business, proprietary issuer,
acquirer, 3rd parties, we try to take a balanced
approach.
... We think it's important to recognize that there are
regulatory issues here.
... There are a variety of different use cases - first time
usage, repeat users, to card on file, multiple iterations to
frecencies... what user is given in terms of ability to
prioritize. Other perspective is from acquiring perspective...
merchant has opportuity to influence payment preference on what
they choose to accept or not
... The goals of what I think the WPWG have been trying to
achieve - making reference to original charter - level the
playing field.
... If you give merchants ability to do preference... makes it
difficult to keep that playing field level, generates a
bias.
... When you start adding ability for merchants to pick and
choose - that starts to interfere w/ consistent user
experience... we wrestle with merchant request... I understand
the challenge, but hopefully it helps to understand the
perspective we take.
evgeny: Some use cases where merchant needs b/w/listings - if merchant has agreement w/ a few PSP's, one of which accepts only wallet payments, while other accepts, say, card payments as well, we need an option to say using a standard that one payment app can be used with one set of methods and other payment app with other set.
Steve: The merchant risk that's involved is also important... good wallet vs. bad wallet... Apple Pay has a good system for validating card. Merchant might come across wallet w/ cards through the system... define in the specs to create infrastructure to verify... merchant not invoved in whitelist/blacklist... for example, chrome downgrading a CA.
oyiptong: Wrt. merchant fraud, if
payment response says its due to basic card, the only way to
block that is to block basic card... if there is no info around
origin of card number...
... If there is additional information, that might help.
Ian: We don't respond w/ origin
back to merchant, unless merchant can say "don't use that
origin anymore". In interest of time, let's keep moving
forward.
... Thanks for getting this started.
... We did decide that we didn't need anything special for
partnership proposals.
... For this particular merchant need, no need in the
spec.
... wrt. quality assurance... payment handler origin - raises
privacy issues... native payment apps don't have origins...
browser basic card store, you don't learn that... payment
handlers can communicate w/ merchants... if you don't share the
information, we are not preventing payment apps anyway.
... That may be doable in any case, it's not that harmful to
send payment app origin back... that's a perspective... no
conclusion on that.
... open window algorithm is still open... default handler
icon.
<Ian> scribe: Ian
Manu: Why do we need a polyfill?
Existing browser market
... if you want consistent experience around payments, polyfill
and be useful. Note that details do matter but I am moving
quickly for this presentation
... we have implemented both PR API and Payment Handler
... a polyfill is a pure JS implementation. Our goal with the
polyfill is to get older browsers to do payments using the next
user experience
[list of browsers supported]
Manu: With polyfill we add
another 50% of the browser market (not that people are using
it, but how many people could have the feature available to
them). There are some security
concerns we are worried about
... Similar coverage with the payment handler polyfill
... we have worked on passing the test suite
... we think we can get to about 95% but you need native
implementation for some of the tests
... the big question we have for the group is this - are
implementers (e.g., merchants) waiting for the stuff to be
widely deployed in browsers, or could the polyfill be part of
your strategy
... that will help us determine whether we continue to work on
it.
Jenan: How are you handling canMakePayment? Where are you vaulting PANs?
Manu: The sheet has to be served
from a single domain
... that's the scary thing about the polyfill.
... there are ways to mitigate phishing
[Manu demo]
Manu: I install a payment
handler. The polyfill site requests consent from the user
... then the payment app stores some data
... then on the merchant site you push the buy button
... the polyfill mediator site shows the sheet
... the merchant doesn't see the data; the mediator site
does
IJ: I think that this is very
similar to a third party service provider providing a
sheet-like experience in a web form
... Is this basically like current practice styled like the
sheet?
Jenan: What is the proposal? That merchants include the javascript on their page?
Marcos: Would you take this
experience as being as good as a Stripe experience?
... that's what's being asked.
alyver: I am still confused .... you mentioned in the blog that there's a discoverability problem...does the polyfill have to be installed beforehand?
<marcosc> MC: the polyfill is just a progressive enhancement
Manu: Here's how stripe and
shopify would have to deploy this today.
... for a fallback experience, you'd either have to build the
experience yourself, or install this polyfill...to give them a
near native user experience.
... so the result would be a more unified experience across
browsers, without having to wait for deployment to get large
enough for you to switch over
shift4sms: A big factor for merchant acceptance is how reliable is canMakePayment()
MattSaxon: What's the behavior for browsers that support payment request but don't support payment handler?
Manu: Good question; we don't
want the polyfill to stomp on browser implementations.
... and what happens if browser never implements payment
handler API?
... and what if polyfill supports a feature but browser does
not?
... another issue is that the polyfill cannot detect native
apps
... Whatever we do needs to be ok with the browser vendors.
Ken: We see this as going back to the request that MC made; we see polyfill as good for transition and good user experience
mweksler: I want to echo something that Jenan commented on - where does the data get stored?
Manu: Unless we get buy-in from a lot of organizations to share the load......
mweksler: Because you are not storing card info, you won't support prefill, is that right?
Manu: Card information is stored by the payment app.
IJ: What about shipping address?
AdrianHB: What persistence is
there cross domain? It only works if every merchant uses the
same polyfill library
... this implementation of the payment request doesn't store
payment details...you need a payment app for that.
mweksler: I can use the same card on airbnb but not on other merchants (due to cross-origin)
Manu: It is possible for us to add that functionality to the mediator but we don't feel comfortable doing that right now
Jenan: I am still not sure to
understand the value proposition to merchants
... is the proposition that with the polyfill you can throw
away your traditional payment flow
... if that's the case, I think that is missing the value of
payment request
... we would tell merchants today you need to have both PR API
and your fallback existing form.
... I don't see any merchant being able to throw away their
traditional payment forms
... stripe tries to make it possible to create a traditional
form and also have PR API
... where PR API support is nice and has value over traditional
flow, otherwise allow user to follow traditional flow
... e.g., I might want to pay with a new card that I don't want
to enter in the browser...firefox allows you to not save card
in the browser
... I don't think it's a 100% replacement, so I'm not sure what
the value of the polyfill is
... over a traditional form.