nicktr: Welcome to the meeting. I co-Chair the WG along with Adrian Hope-Bailie. Thanks for coming to the meeting
[Nick walks through the Agenda]
[Jonathan Grossar slides on SRC and Payment Request]
Jonathan: When we met at TPAC, we
discussed improving security through strong auth and
tokenization
... among the benefits we highlighted were the reduction in
fraud, data compromise, better lifecycle management, regulatory
compliance
... one key discussion topic was how to bring different
standards together under PR API flows
... we wanted to ensure that EMVCO, FIDO, W3C specs complement
one another
... the net result of the discussion was to see the specs as
complementary
... my colleagues at MC have worked on a demo to show three
things:
Jonathan: An assumption of the demo is that the user has already enrolled a card. This is a returning customer whose identity is already known at the time of the transaction. The demo shows two paths: (a) no step-up (b) 3DS requested by the merchant with step-up
[First demo flow is usual PR API flow: choose a card and pay; no auth]
[Second demo flow involves 3DS preference expressed by the merchant. Uses WebAuthn]
[In second experience, auth happens after "Confirm"]
[Demo shows Jonathan authenticating via fingerprint]
PatiP: Do you have any fear that
auth may result in card abandonment?
... Could I choose a card that does not prompt me for auth?
Jonathan: There are different reasons for step-up, including regulatory, or risk assessment by the issuing bank
AdamSolove: What is the status of the demo? Is this talking to SRC backends?
Jonathan: This is a live demo in that it uses PR API and PH API, but it only simulates getting backend credentials.
lte: If an issuing bank wanted to do a step-up, can the merchant request that not happen?
Jonathan: When the merchant receives the response, the merchant can decide not to involve the challenge flow.
rouslan: The APIs that Jonathan is using support the use case where the payment handler lets the merchant know that a 3DS could happen, and the merchant can respond.
Trent: Who is performing the 3DS call? Merchant or payment handler?
Jonathan: Payment handler in this demo, based on request by the merchant.
Jonathan: Here we have been using
a single payment method, and a single payment handler
... we could have also had a native payment handler within
Chrome (à la Basic Card)
... so the user experience in this demo enabled us to "skip the
sheet"
[Block diagrams, then detailed flow diagrams without step-up]
AdrianHB: How does the payment
handler/DCF know which SRC programs to call?
... where does the list of SRC programs come from?
Jalpesh: Given a card, the DCF
will know which SRC program to interact with.
... The DCF knows which SRC systems it wants to have a
relationship with
... Cards can be fetched in background
nicktr: Regarding the directory of SRC systems; that's a question I asked EMVCo; there is no directory
[Block diagram 3DS with step-up, then detailed flow diagrams]
Adam: How are you implementing this in a payment handler? Can you load iframe?
Jonathan: For this demo we used
Web Intents, but you would not do that in real life
... but you might do it differently in real life
Adam: Will it be possible in the real world to run an iframe in a payment handler?
Jonathan: The merchant doesn't
control the issuer's backend
... The merchant can invoke 3DS or the payment handler can
(based on merchant prefs)
Jalpesh: Is Adam's question what
happens if the issuer cannot do out-of-band? If so, the issuer
might choose to do some other type of step-up
... it's also an issuer choice to suppress the step-up based on
risk analysis.
AdrianHB: my understanding of 3DS is that merchant gets back a URL....but if the payment handler is doing 3DS, will it be possible to invoke the URL from within an iframe?
Rouslan: Is the question whether you can render an iframe in a payment handler? If so, yes. You can also redirect to another URL, but that origin cannot interact directly with the service worker of the (initial) payment handler
AdrianHB: Who will publish these payment handlers?
Jonathan: In this demo we simulated a "common entity"; but this payment method could also be implemented natively.
AdrianHB: Card networks? Gateways?
IJ: In short, I hear AdrianHB asking "who raises their hand to implement the payment method?"
AdrianHB: There are new roles, and some registration as a DCF will be required I assume
lte: We know implementations are happening; parties are playing the DCF role are known
Jalpesh: You are correct, and
that's without PR API. In the PR API paradigm it's different. I
think in the short term Visa will play a role of DCF for Visa
cards.
... but we don't think that's the end state.
... we want to get to a simpler user experience where the
payment handler is native to the device
... a lot less friction in the UX
lte: If this group wanted to do some piloting, who should we talk to?
Jonathan: We are speaking with PSPs. But within W3C, there's also a possibility of browsers playing a role.
benoit: I can see how this works
when there's a single DCF...what do you do when the merchant
talks to multiple PSP-type things in a global ecosystem?
... I don't know what payment methods to offer until I know
where that person is, what currency they are paying with, and
what payment instrument is selected.
<AdrianHB> ian: some things must be figured out in advance of calling PR API
<AdrianHB> ... there is some feedback via events once the sheet is displayed
<AdrianHB> ... after the sheet is hidden you can select how to handle the response
<AdrianHB> benoit: how do I know which DFC's to talk to if I have multiple
<AdrianHB> ian: this is what we are working to figure out in the Card Payments Security TF. This would require adding some additional data to the request. Our next work is to determine what data is necessary for this sort of use case.
<AdrianHB> ... we may need to add additional capability matching criteria
Jonathan: We have not yet ironed out the parameters that are sent through the PR API call
<danny_WP> The questions is still about how we identify the user to the SRC systems or is that through session cookies auth tokens etc?
Itai: As a merchant, when we take PR API, is it something that as a merchant I can parametrize and reduce integration costs?
Ian: Yay, exactly!
lawrence: You mentioned the DCF
is responsible for getting the card...in the case the consumer
is known and banks with two banks
... how would visa know who the consumer is and then fetch the
correct card?
Jonathan: The first step is to
get the user identity. The demo assumes the identity is
known.
... The DCF fetches cards from N systems using that
identity.
Lawrence: How do you know the identity?
Jonathan: In this demo, an email.
Jalpesh: For Visa, when the card
is originally registered with the device, there is an identity
sent by the DCF and the card is bound to the identity.
... where the fetch is real-time or async that's an
implementation detail.
... but this is transparent to the merchant and consumer
Lawrence: So during enrollment, the consumer does something to authenticate?
Jalpesh: Yes.
... the identity may or may not be tied to the device
Lawrence: What does the user have to do for identity proofing?
Jonathan: The authentication
that happens during
the demo is about 3DS flow. The identity question is
implementation specific.
... Card data is provided at enrollment along with identity
proofing
NickTR: Enrollment is outside of
PR API
... one question is who defines the SRC payment method....will
there be N or 1?
IJ: Next step for the task force is to look at payment method data, options, URL structure, etc.
rouslan: One of the questions
that floated around was "how does the payment handler know your
identity?"
... I think the best answer to that is that the payment handler
should be using openid connect or oauth
... and get assurance from an identity provider such as
Google
... the payment handler can then use the information to
retrieve cards from SRC programs
<SofianeCANTON> Webauthn or Fido2 can be an assurance for replace the 3ds process ?
rouslan: when the user enrolls, the user has to perform the same step with their identity provider
Ian: WebAuthn could be used on its own, or as input to 3DS risk analysis
Alaric: Does this integration contemplate the model where, instead of selecting the payment handler, the user selects a series of options before authenticating?
Jonathan: The demo shows a single payment method, but the merchant could accept multiple payment methods
AdrianHB: The demo shows a single method, so the sheet (where methods are shown) is skipped.
<Trent_Addington> Is the w3c demo site https://paymentrequest.show/demo/ pci-dss audited/certified/etc? I see it displays the full PAN in the "result"
<Ian to Trent> The demo site is not PCI-audited...its just intends to illustrate data and flow
benoit: When you click the
selector to pay with SRC...what if I have cards not in SRC. How
do I know which button to click to get my card?
... ...consumer does not card whether card is an SRC card.
PuneetS: Would it be fair to map SRC-I to payment handler?
Jonathan: The SRC-I function invokes Payment Request
Jalpesh: SRC-I continues to
integrate on behalf of the merchant with the SRC experience.
The SRC-I is primarily doing the invocation of DCF. In PR API,
it's the same.
... so the PSP only needs to talk to one DCF (as it
were)....single implementation without SDKs provided by
different parties
PuneetS: Who will develop the common DCF?
Jalepsh: That was AHB's question. Could be PSPs, browsers, issuers
Jalpesh: Regarding DavidB's
question about user experience. If Merchant supports both Basic
Card and SRC, it's up to the payment handler to determine
whether to support one or both.
... I would argue that the customer does not need to know the
difference
[Break]
NickTR: SRC is still
exploratory
... not sure we yet know how all use cases will be
addressed
... I am encouraged by the effort to increase security, offer
more choice, etc.
... good to remember that different parts of the world use very
different payment methods
Steve_Cole: How do we resolve these issues between something being basic card or SRC?
AdrianHB: We still need to explore in payment handler land how instruments are presented
[The Payment Handler API supports "in sheet display" of payment instruments, but that is not currently implemented by browsers]
AdrianHB: May make more sense to the user to present instruments for selection, rather than just wallets
<AdrianHB> ian : One SRC payment method design consideration is short string v. URL-identified.
<AdrianHB> In addition, if we go with URL-identified, not sure whether there should be one or more (though one is likely preferable from a usability perspective).
<AdrianHB> advantage of URL is that each program can control which payment handlers are authorized to handle SRC payments for their program
<AdrianHB> advantage of short-string is simpler for developers; but sets an expectation of built-in browser support
<AdrianHB> There was also an early proposal for a hybrid where browser converts short-string to URL(s) on the fly
<AdrianHB> issue is maintenance/implementation burden on browsers
Jalpesh: We don't want a "Visa
program" and a "Mastercard program"
... the whole intention of SRC is to not have N systems
... merchants will still have a choice (e.g., "just visa
cards").
<SofianeCANTON> +1
Jalpesh: we don't want acceptance to be complicated by having N acceptance policies
Jonathan: Agree with Jalpesh. We
also don't want to have a "brand selector"
... people don't necessarily know what kind of network brand
card they have
IJ: Do the brands needs to authorize DCFs?
Jalpesh: DCFs will need to integrate.
<AdrianHB> ian: from UX side we want the browser to only display authorized handlers (after consulting one or more payment method manifests).
IJ: How do you plan to white list DCFs?
Jalpesh: We can publish that list.
<AdrianHB> ian: by defining requirements we can figure out design details
<AdrianHB> ... I'm hearing you say that you'd like to use manifest
<AdrianHB> jalpesh: yes
<AdrianHB> ian: a manifest is published at an origin so either each program hosts one or they jointly select an entity to do this
<Zakim> AdrianHB, you wanted to differentiate between UX and API design
AdrianHB: I want to make the
point between the design and the UX
... what you put into the payment request is a set of payment
methods
... merchant says "I support SRC with Visa or whatever" and the
user experience will get for example, a single DCF (for
multiple SRC methods)
... Another advantage of URL-based is just-in-time
registration
... Card brands could host a common manifest for everyone.
<AdrianHB> ian: URL based method identifier gives to control to an entity that owns the origin
Jalpesh: There are geographies
where the international brands are not the only schemes
... Short string seems more attractive when there are more
schemes
AdrianHB: The question is where
is the implementation burden
... burden either lies with browser or developers (to write more URLs)
<Zakim> nicktr, you wanted to talk about potential role for EMVco, or task force at W3C
nicktr: The short strings were
put in there initially to bootstrap the ecosystem (for
basic-card) also because it was easier for developers
... our security architecture around manifests is built around
origins
... if you use short strings then the burden of deciding who is
an authorized payment handler falls on the browser vendor
... there is a common place where SRC systems will come
together..namely emvco
... I had hoped very much that we'd get an engagement with
emvco for the purposes of hosting a manifest
... alternatively, we hopefully have the src systems and we
could maintain a manifest as a W3C artifact, but W3C is not
historically suited to that role
Jalpesh: I think emvco is unlikely to want to do this
NickTR: I understand emvco does not do business roles, but this is a spec.
Jalpesh: W3C might be a better place to maintain the registry
Marcos: W3C does maintain a small
number of registries.
... it would be interesting to explore various solutions to
this. But the browsers are not the best places to do
this.
... people will have different browsers and versions of
browsers
Ken: We don't want a brand
selector. Ordering of payment methods is another topic
... from amex perspective, it's much easier to work with a
handful of browsers
Benoit: What prevents somebody from making a payment handler that is a card skimmer?
NickTR: With SRC, the payload
that is returned is not the card number.
... if you masquerade as a payment handler you can skim
numbers
Jalpesh: The DCF has to be registered before it is published
Itai: How do you prevent registration of bad SRC systems?
Benoit: Also, merchant site may be hacked.
Jalpesh: Having a malicious SRC system is a different issue than issues related to security for an authorized SRC system
Rouslan: There's a lot to discuss
here. One salient point is that all of this can be done today
(e.g., cross-site scripting attackks)
... the browser cannot do much about that
... if we use PR API, the browser can do more. For example,
ensure the security of certificates (e.g., no self-signed
certificates)
... this is possible because we are using the API to tell the
browser it's a payment context
... we also use the Safe Browsing database. Chrome prompts the user
when a site is known to be a bad actor. User can override that,
but the browser could also disable payment handlers from these
malicious sites
AdrianHB: Imagine there is an src
short string. I trust somebody else to have a list of src
systems
... for each "valid" src system there are N "authorized
handlers" (For the authorized handlers, that's a payment
method manifest issue). Vut we have not defined
who is a valid SRC system.
<AdrianHB> ian: who should maintain the registry? Does anybody think it should be W3C
(IJ: notes that this is analogous to W3C's registry of networks)
@@: Does the merchant need to know this is SRC? Suppose there are four payment methods. Only BobPay supports SRC....then the browser only shows BobPay
<AdrianHB> ian: the verification of handlers is done using the manifest to avoid bad actors even showing in the user's choices
PuneetS: The payment method
manifest and the payment handler API are designed to delegate
payment method management
... in contrast with short string. For short string, is it
fair to say the registry would either be w3c or the
browsers?
Ian: Yes
PuneetS: So the question for merchants is how much they want to rely on who self-publishes as a payment method
<AdrianHB> ian: the question of who publishes the list, I was mentally pushing back on W3C doing except that we already this for basic-card
<AdrianHB> ... the list of 'supportedNetworks' is maintained by the Web Payments WG and the browsers validate the input against this list
Jalpesh: Short string is both developer friendly, and there's some trust in centrally managed registry
srini: W3C already has the
registry of supportedNetworks
... so it makes sense for W3C to be "a" registry for SRC
systems
Marcos: There are security issues. And also "registration" in the registry
alaric: Backing up...suppose I'm
a merchant I want to offer SRC. I go to my PSP. That entity
integrates with SRC systems and then those SRC systems offer 20
DCFs each in the future.
... in this PR API ecosystem, you can not rely on the PSP to
get the payment handler to plug into the SRC systems.
ital: Just because I accept amex
doesn't mean I accept it through all wallets
... so even more complex.
AdrianHB: I hear you describing PSP as SRC-I
Alaric: Will the merchant trust payment handlers to do this work that they trust the SRC-I to do?
<AdrianHB> ian: the heart of PR API is decoupling. The merchant calls the API and waits for the browser to return a response that was determined via multiple possible flows. There are advantages and disadvantages. The advantages are especially difficult in the case of using an SRC-I which usually does a lot of this work for the merchant
Jalpesh: +1 to what Ian said.
Merchant has a choice of whether they want SRC or not. They
also have a choice whether to use PR API or not.
... and the consumer chooses a payment handler. So it's not
really a "browser" choice.
Alaric: If the browser is orchestrating a journey, and it doesn't look like "basic SRC" it raises question about whether SRC is a backend spec or a user journey
<Zakim> AdrianHB, you wanted to suggest that building the payment request with multiple URL's is not as hard as it sounds
AdrianHB: I was on the queue
originally to say that building the request with multiple URLs
may not be as difficult as it sounds.
... so maybe simplifying for the developer may not be as
necessary
... Alaric's comment emphasizes this point to me
... PSPs can mask the complexity for the merchant anyway
... so I suggest that we NOT use a short-string approach
Justin: +1 to AdrianHB. I think it would be weird for W3C to host a registry of SRC systems
Puneet: I think there are some
merchants that will rely on PSP SDKs, and others that will pick
and choose
... the architecture should support both flexibility (for
sophisticated merchants) and simplicity (via PSPs)
<AdrianHB> ian: to satisfy the need for programs to manage the handlers we want URLS
<AdrianHB> ... to ensure the set of known-good SRC systems is known we need a registry
<AdrianHB> ... we don't need to worry about making this easier for developers because in a lot of use cases a thrid-party deals with complexity of building the PR for the merchant
Jalpesh: I still don't fully understand how we avoid the registry of supported networks
IJ: I agree you need a registry. Justin's point was that he didn't think w3c should host it.
Jalpesh: There are a small number of browsers....,there are millions of other parties...we want to simplify life for millions
AdrianHB: It's important to
remember that even if we go with multiple payment method
identifiers it would still be useful to have a standardized
payload
... we can still try to solve the identifier problem, but in
any case we should have a standardized payload
Next steps:: The Card Payment Security Task Force will work on (1) an SRC payment method data model based on the Mastercard demo; the payment method could be supported in-browser or by third-party payment handlers (2) the short string v. URL question (3) means such as the payment method manifest or secure browser database to lower risk of unauthorized payment handlers.
Luis: I'm with NACHA. We play a
variety of roles around ACH. We bring together industry
stakeholders to enhance the network
... we would like to make it easier for merchants to accept
ACH
... we are working on a prototype using PR API...not quite
ready to show at this meeting but we'll show it as soon as we
can
... is ACH on people's radar for checkout?
Trent: Yes
Laura: Yes
NickTR: We are interested in
Direct Credit in EU
... we've done some work on credit transfer specs
... as a WG we've been interested but struggled to get live
implementations
... I've not seen live implementations "break cover" yet
... Adyen in the UK market have launched a direct credit
payment method on KLM
... not through PR API
... just illustrates the use case
IJ: For ACH or any other payment method, you will face the same questions we just covered (on short string, URLs, who will distribute payment handlers, etc.
Luis: We have had some conversations and are still figuring that out...I am looking to the group for recommended next steps
benoit: ACH and SEPA are similar.
We end up seeing merchants end up not wanting to use something
like SEPA because it's so consumer-centric
... if merchant accepts it, they may wait a bunch of days
before shipping the product.
Luis: ACH is a batch process, 2
day settlement (though often 1). Returns can happen during that
period. We are fleshing out those details.
... one of the things we are working on in the prototype is, at
minimum, doing some sort of account validation
... we may also check balances. (but that may not be in v1)
<AlanB-W3C> [Lanny Byers from FirstData arrives]
Luis: I agree we need to address the returns process
lte: Overall we are interest in
ACH and other alternatives being available through PR API as
long as these are competitive alternatives
... We'd like to be at the table (whether at W3C or elsewhere)
to work on this
AdrianHB: How is it going to
work? Ultimately the payment methods we want to support only
work if the merchant can get back a response that the payment
is "complete" (whether real-time or they are confident it will
settle)
... one off the biggest challenges with credit is the extra
friction where the user at the beginning has to choose a
bank.
... there's a company in South Africa that does this through
screen scraping (but it's pretty easy given small number of
banks)
... that's another problem to solve...figuring out how to
simplify the bank selection user experience
... e.g., your payment handler is from your bank.
... you have an "ACH" payment method, and the user has a
payment handler from their bank
Itai: How does the user get the payment handler?
AdrianHB: You can get it on the bank's site
Ian: One of the advantages of the manifest is the machine readable info that in one instance can be used to get a default payment handler for a payment method. So there is a distribution model that helps bootstrap the ecosystem. This isn't available for short-string payment methods
AdrianHB: Another distribution
mechanism is "apps"
... browser can invoke a naive app on mobile
Rouslan: introducing payment
handlers
... what are the advantages?
... for apps:
... - distribution
... - development efficiency
... - enhanced security
... - enhanced UI
... a payment app will run wherever chrome runs
... integrating with safe browsing capability
... (e.g., self-signed certificates will prevent payment apps from
running)
... UI allows merchants to stay in context
... advantages for merchants:
... - easier integration and testing
... - more consistent UX
... (shows web-based and native payment apps)
Rouslan: There is no "Just in time" installation for native payment handlers
[Demo of Web-based Google Pay payment handler]
Rouslan: Google pay web-based payment handler is in production
Rouslan: demo shows "can make payment" - handler is available
<Ian> [Current payment handler capabilities]
Rouslan: payment handlers are progressive web apps that can also do payments
<Ian> [Features coming soon]
<Ian> [How can payment handlers do more?]
rouslan: payment handlers can be
much more than "just another wallet"
... I would like to start a discussion on how to extend their
capabilities
itai: Where did the out of stock use case come from?
Rouslan: e.g., tickets for a concert
Itai: We're giving native card
information but nothing for the merchant to use to create any
security for the transaction.
... merchants need to do a fair amount of things before
authorization....they need to interrogate customers first
... what other security can payment handlers provide?
Rouslan: Might be through
delegation (e.g., oauth); value of secure identity providers.
Also, use of tokens.
... in short, there is security baked into payment method data
but that's orthogonal to the payment handler API
... payment handler API lets any payment app be a first class
citizen for making a payment
itai: In today's world, there is
card present (CP) and card-not-present (CNP)...in the CNP environment,
merchant has most of the liability.
... we want the merchant to have a CP liability.
... tokens and cryptograms are used
... the issue with the payment handler, are we just getting a
token? If so, that's the same as card-not-present
... so an additional feature of a payment handler would be a
liability shift
ian:what are the expectations around SRC and liability shift? My observation is that what you've described is specific to a payment mehtod
[Use case of split tender for partial authorization]
benoit: As far as what we want
payment handlers to do; I like the idea of effort toward
liability shift
... I think payment handlers should do those things that are
sufficient to getting liability shift
... the payment handler should "follow all the rules so that
the payment method is done right"
Rouslan: Payment handlers can distinguish themselves in the market this way
srini: What we see happening with
some Web sites with PR API....the show() method is being called
despite the fact that canMakePayment() returns false.
... can we prevent the developer from making that call?
... Specifically for payment handlers, as a consumer, I'd like
to see the history of my payments made within the
browser.
... I realize that's a payment handler specific feature
... but it might be interesting to add an API to fetch details
from a payment provider
Rouslan: Each payment request has
a unique ID that can be used in the history creation
... maybe browser can aggregate transactions
... I heard similar concerns before where the payment handler
doesn't want to be shown when interacting with a given
merchant. That's hard to prevent on a web page generally (e.g.,
Site A can include Site B and B cannot easily prevent)
... the way that it works today, is that the origin of the
merchant is sent to the payment handler, which can reject the
event immediately
... but that may not be the best UX
AdrianHB: One of the points that
you (srini) just raised was "user friction." We can't solve
"business problems" that are inherent in a payment method.
Payment Handler and Payment Request create a framework in which
it is easier to solve those issues, but those issues are
payment method specific.
... Our question for you is: if you have an ideal payment
method solution for a business problem, tell us what in the
APIs don't allow you to pursue those issues
Marek: Rouslan asked about how wallets can provide value. I think adoption is an important topic. Ubiquity across browsers is important.
AdrianHB: +1
rouslan: I call for browsers to implement Payment Handler API
AdrianHB: It's a 2-sided
market.
... I think we were at a stage where we might need signals both
from browser vendors and payment handler publishers.
Marek: Is it the quality of payment handlers? Or volume?
AdrianHB: If we could come to ground on how SRC will work as a payment handler, and say "this is a roadmap for getting rid of Basic Card" and it uses payment handler, then that's the way forward
IJ: Teddy, tell us about Paypal's wish list
Teddy: We are platform agnostic
and want to give users consistent experience. We have been
exploring with Google about a PayPal handler. One challenge we
see is lack of consistent support for the API across
browsers.
... we see Payment Handlers a potentially offering a much
better user experience, but the fragmentation is a
concern.
... in terms of functionality for payment handlers, I like a
lot of what Rouslan talked about (e.g., just-in-time install,
ability of consumer to stay on the merchant site both on
desktop and mobile),
... I think those are important user experiences, coupled with
security features (e.g., WebAuthn)
... there is an opportunity for us to take the experience to
the next level; the biggest obstacle is a consistent experience
across browsers.
<Ian> Implementation report and tests with fewer than 2 implementations
Ian:the director has approved our transition request for Payment Request API to Candidate Recommendation. I anticipate that version 1 of Payment Request API will look very much like that specification. Now we need two independent implementations Which we hope will take 10-12 weeks
marcos: we're in a good place for implementations
marcos: chrome 75 is looking good
marcos:Edge is moving to a chromium base
ian: there's slim chance that we have to drop a feature but we don't want to that
marcos: I think we are unlikely
to have to drop a feature
... regionCode and languageCode have moved to v1.1
<Ian> View of PR API upcoming milestones
ian: if we publish the CR on 25th April and then in the best case we publish the PR on 6th June, then we could get to recommendation by 11th July
adrian: question to the room: is anyone waiting specifically for the Recommendation in order to do any work or distribute any products?
<Ian> [Nobody raises their hand]
ian: payment request is implemented by the "mediator," usually a browser but it doesn't have to be (e.g., Facebook has expressed interest)
ian: Regarding improvements to the user experience, there have been several ideas, including from Shopify and Matt Saxon's issue 834. Do browser vendors want to report any progress?
Justin:(Google) We have been focused on passing tests, but we are still planning to address UX issues that have been raised.
aestes:(Apple) Same here.
zouhir:(Microsoft) Looking to experiment in the next few months
marcos:(Mozilla) We are also looking to see where payment things go
ian: any other experiments?
marcos:From Mozilla's perspective, browser vendors are not in the business of creating payment experiences; people who are in that business should create them. So people should make awesome payment handlers.
AdrianHB:Is there anyone prepared to share plans to use PR API?
<Ian> [No hands]
<Ian> [After discussion we agree to two breakouts: (1) a Web payments ecosystem primer and how SRC fits in (2) payment handler new features.
<Ian> We minuted the first session directly; the payment handler breakout reported later.
<Ian> PuneetS: I'd be interested in hearing about the evolution of the specifications
<Ian> sophie: I'd like to hear about the terminology (payment handler, payment method, etc)
<Ian> Lanny: I'd like to hear what problem we are solving
<Ian> benoit: I want to hear about non-card payments
<Ian> ian: it's annoying and cumbersome to type information into sites again and again in the purchase journey - why not store the browser?
<Ian> ian: the browsers were already doing that in autofill but for a merchant you need to provide a form
<Ian> ...the motivation was to get rid of forms, and just store the re-usable data in the browser via an API
<Ian> ...and at the same time, we will improve UI
<Ian> ian: the original thought was to make things easier by "pushing a button and speeding things up"
<Ian> Puneet: did basic card pre-date payment request?
<Ian> ian: no, it was simultaneous with payment request
<Ian> ...then we looked at 3DS and tokenization - but then SRC came along
<Ian> ...one vision of SRC is that it provides an umbrella for those things
<Ian> laura: please don't sacrifice what you're doing in W3C to meet SRC as a spec
<Ian> ...I'm concerned that we're spending our energy on SRC rather than doing tokenization in other ways
<Ian> ian: we're in the position to work on more than on payment method at the same time; participants in the group drive the work.
<Ian> laura: I'm reacting to you saying that we are pausing the tokenization work - I'm saying that a broader tokenization is useful
<Ian> ian: AdrianHB raised at TPAC last year whether we should have a generic tokenization spec
<Ian> ...and if participants in the WG want to work on that then we can
<Ian> ian: one of the questions that we took up early was "are we building a payment or a checkout API"?
<Ian> ian: from the beginning, we wanted a point of extension so that non-browser third parties could also build payment applications
<Ian> Puneet: why do basic-card alongside URL based payment methods?
<Ian> ian: short strings are easy for developers, URLs allow extension and control (the latter motivated by Alipay feature request early on)
<Ian> ...we wanted to decouple payment from data
<Ian> benoit: couldn't you argue that existing forms that send and update prices is the same as the payment sheet
<Ian> ian: the motivation was for address to be re-usable data
<Ian> http://www.w3.org/2019/03/poc/poc-mini.pdf
<Ian> ian: (shows flows)
<Ian> sophie: skipping the sheet happens in what circumstances?
<Ian> ian: one matching payment method and the merchant does not need shipping address or customer contact information.
<Ian> sophie: what determines the ordering of the payment handlers?
<Ian> ian: the browser ("Frecency")
<Ian> alaric: (shows socks bought with payment request)
<Ian> alaric: if you don't do everything that checkout does, how is payment request relevant?
<Ian> ian: there will be legacy checkouts for some time to come
<Ian> nicktr: As Richard Dawkins has said: half an eye is better than no eye
<Ian> puneetS: SRC is just payments - it's interesting that payment request is "payments++"
<Ian> puneetS: basic-card short string - sounds like it was a proof of concept
<Ian> ...what was the rationale for not having lots of short strings?
<Ian> ian: blame nick
<Ian> ian: but in short it was about security and maintainability
<Ian> ...we keep churning on this question - the main advantage of short strings is ease of use by developers
<Ian> Itai: with payment request, things happen outside the domain of the merchant
<Ian> ian: yes - that's right. Payment request is easier, but cedes some control from the merchant
<Ian> ...(ian explains hasEnrolledInstrument)
<Ian> ...merchant doesn't get to control which handler is used by the user
<Ian> Itai: follow-up: can I repeatedly call canMakePayment to enumerate which payment methods are available?
<Ian> ian: no - it is rate limited
<Ian> Itai: I want to control which handlers are used
<Ian> trent: the *Pay would know that credentials were delivered to a particular merchant
<Ian> Itai: when I have selected paymentHandler, who chooses the credential preference
<Ian> ian: the handler
<Ian> PuneetS: short-string approach hands control of which handlers are usable to the browser
<Ian> ian: that's correct
<Ian> ian: the question is who controls the manifest
<Ian> jalpesh: is payment amount in basic card?
<Ian> ian: no, it's in payment request
<Ian> jalpesh: only chrome supports payment handler
<Ian> ian: correct
<Ian> (we examine payment handler API)
<Ian> Itai: the issue is that the payment handler is getting more information about the transaction than previously
<Ian> ...(e.g. amount, merchant name)
<Ian> steve: is there a requirement to blacklist payment handlers?
<Ian> ian: that's a possibility but difficult (whitelisting might be easier)
<Ian> Itai: whitelist is easier
<Ian> ...merchant should have choice too
<Ian> ian: the vibe I am getting is handing off the arbitrary basic-card handlers is not a good idea
<Ian> ian: we did have a "recommended payment apps" concept but that was dropped in favor of the payment method owner managing compliant handlers
<Ian> patiP: why is billing address in the browser?
<Ian> ian: great question. the flag is in the payment request so that we can use the event model
<Ian> (ian explains architecture)
<Ian> ian: web authentication fits around the payment handler
<Ian> AdrianHB: In the payment handler breakout session, we talked through things we would like to explore for a future version of PH API (or even the current version)
<Ian> ...first topic was merchant validation. This exists in apple pay today. One question is whether and how to standardize this validation.
<Ian> ...the current implementation in Apple Pay is an event that is raised by PR API which tells the merchant "for me to you continue, you need to be validated at this URL"
<Ian> ...we think this event will be generally useful across payment methods
<Ian> ...another topic we looked at was Web Authentication. Anything to do special for that? One thing we talked about was whether the service worker can simply prompt for a fingerprint ....today service workers would not support that.
<Ian> ...,the general sense that it was not a priority to do biometric auth without having additional context
<Ian> ...another topic was how to exchange address information more fluidly (e.g., payment handler has addresses that could be shown in the sheet)
<Ian> ....and we've also heard the use case of the shipping address sent to the payment handler (e.g., for fraud mitigation or payment-specific needs)
<Ian> rouslan: My read of the consensus around the table was, in order to be able to provide a first-class payment handler experience, you need to enable the payment handler to say to the browser "I handle shipping addresses, don't worry about it."
<Ian> ...so the requestShippingAddress flag could allow a "skip the sheet" experience for a payment handler that claims to support shipping addresses.
<Ian> AdrianHB: I think this is a higher priority topic to figure out. GooglePay is already doing some of this with merchants, so there is a demand there.
<Ian> benoit: Another motivation for having shipping address info available to the payment handler: export restrictions. The handler may not be able to handle a payment due to where it's being shipped.
<Ian> AdrianHB: We talked about the user experience in the payment sheet...we talked about display of instruments.
<Ian> ...and how would it work in "skip the sheet" scenarios
<Ian> ...if a payment handler has multiple instruments do you still see the sheet if the merchant requests shipping....in short...a user experience discussion
<Ian> Trent: I have a host of use cases to go over tomorrow.
<Ian> AdrianHB: We ALSO briefly touched on the idea of payment handlers being available on all of the user's devices. No standards work, but it would be useful.
<Ian> AdrianHB: Limitation of service workers, browser instance specific.
<Ian> AdrianHB: WebAuthn has an element of this but there is a privacy consideration.
<Ian> ...it can recognize you have been through enrollment on a different device, and it can prompt you for this device.
<Ian> AdrianHB: Another topic - solving for the transaction history topic - potentially standardizing a way for a payment handler to provide some correlation to the browser when a transaction completes, so when I look at the history of payments through the browser. I could have a link from the payment handler for the user to be able to see details of a transaction.
<Ian> Dee: Not happening ! :)
<Ian> AdrianHB: Ability to provide a web component in the payment method manifest so you can create buttons for a payment method. To give payment method owners control over the rendering of buttons.
<Ian> AdrianHB: Last topic we discussed: -how this works in Web view
<Ian:> We walked through some of the history, touched on payment instrument ordering, desire by merchants for payment handler whitelisting for basic card
<Ian> NickTR: In our session we talked about the history of this effort. We got insights into the tensions between the different stakeholders on certain topics such as who gets to see what data. We heard two specific requests:
<Ian> - Merchant can whitelist payment handlers for standardized (short string) payment methods
<Ian> - Merchant preference for ordering of handlers and instruments.
<Ian> Trent: We understand how customers like to pay...they may like to pay us with a specific instrument.
<Ian> NickTR: Thanks everyone for contributing today!
<Ian> [Adjourn to tomorrow]