Web Payments Working Group

02 Apr 2019

Agenda · 3 April minutes


Present (in person)
Trent Addington (Walmart), Giulio Andreoli (Apple), Parveen Bansal (Samsung), Ryan Beaudry (Mastercard), David Benoit (Reach), Guy Berg (Federal Reserve Bank of Minneapolis), Alan Bird (W3C), Lanny Byers (First Data), Marcos Caceres (Mozilla), Lawrence Cheng (Barclays), Jalpesh Chitalia (Visa), Mark Cline (Visa), Steven Cole (Worldpay), Krystian Czesak (Shopify), Philibert Dugas (Shopify), Alaric Eby (American Express), Tony England (Bank of America), Andy Estes (Apple), Dave Fortney (TCH), Ramesh Gorintla (Discover), Jonathan Grossar (Mastercard), Luis Guzman (NACHA), Adrian Hope-Bailie (Coil), Ian Jacobs (W3C), Shahzheeb Khan (Capital One), Vincent Kuntz (ISO 20022 RA), Marek Kurylko (Mastercard), WonSuk Lee (ETRI), Chung Liu (Samsung), Bryan Luo (Amazon), Roy Luo (Samsung), Kinnera Mahankali (Samsung), Chris Marconi (Capital One), Ryan McDonough (Verizon Media), Roy McElmurry (Facebook), Avnish Miduthuri (Google), Takashi Minamii (JCB), Fawad Nisar (Discover), Dee O'Malley (Best Buy), Simon Kindström (Facebook), Patricia "PatiP" Partelow (Ernst & Young), Sophie Rainford (American Express), Raj Sampath (Ernst & Young) Itai Sela (Merchant Advisory Group), Puneet Shah (Adyen), Rouslan Solomakhin (Google), Nick Telford-Reed (Independent), Srini Thirunarayanan (Facebook), Teddy Toms (PayPal), Justin Toupin (Google), Laura Townsend (Merchant Advisory Group), Danyao Wang (Google), Raman Walla (Facebook), Jeffrey Williams (The Clearing House), Young Yang (Wells Fargo)
John Gaitanos (Mastercard), Adam Solove (Stripe), Jeff Gipson (Discover), Matt Saxon (Worldpay), Zouhir Chahoud (Microsoft), Sofiane Boumedine (Canton Consulting), Brian Piel (Mastercard), Ken Mealey (American Express)
Tom Lowenthal (Brave), Kristy Cook (Target), Mahesh Kulkarni (Samsung)


Group photo


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]

Card Payment Security Task Force report

[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:

  1. consumer journey
  2. sequence diagrams
  3. sample of the payment method data

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


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.

ACH and Payment Request API

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

Payment Handlers

Rouslan's slides

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.

Payment Request Update

<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.

Breakout: Web Payments Ecosystem Primer and How SRC Fits In

<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

Breakout recaps

Payment Handlers

<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.

Wrap-up for today

<Ian> NickTR: Thanks everyone for contributing today!

<Ian> [Adjourn to tomorrow]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/04/15 16:19:42 $