Web Payments Working Group

31 Mar 2020



Clinton Allen (American Express / EMVCo), Giulio Andreoli (Apple), Dirk Balfanz (Google), Andrey Bannikov (Facebook), Jorge Barboza (Airbnb), David Benoit, Tomasz Blachowicz (Mastercard), Sofiane Boumedine (Canton), John Bradley (Yubico), Erhard Brand (Entersekt), Jalpesh Chitalia (Visa), Chris Dee (FIS Global), Matt de Haast (Coil), Jean-Luc di Manno (FIME), John Fontana (Yubico), Dave Fortney (TCH), Jean-Michel Girard (Worldline), Jonathan Grossar (Mastercard), Liquan (Max) Gu (Google), Lauren Helt (American Express), Jeff Hodges (Google), Frank Hoffmann (Klarna), Mathieu Hofman (Stripe), Adrian Hope-Bailie (Coil), Ian Jacobs (W3C), Manoj Kannembath (Visa), Joshua Karoly (Netflix), Kris Ketels (ISO 20022 / SWIFT), Mahesh Kulkarni (Samsung), Vincent Kuntz (ISO 20022 / SWIFT), Marek Kurylko (Mastercard), Florent Lambert (Lyra Network), Mercia le Roux (Entersekt), Bryan Luo (Amazon), Melanie Maier (Entersekt), Ajay Maddukuri (American Express), Takashi Minamii (JCB), Fawad Nisar (Discover), Gerhard Oosthuizen (Entersekt), Kacie Paine (MAG), Jay Patel (American Express), Gavin Phillips (Mastercard), Brian Piel (Mastercard), Anne Pouillard (Worldline), Jean-Yves Rossi (Canton), Sophie Rainford (American Express), Hervé Robache (STET), Simon Rodway (Entersekt), Peter Saint-Andre (Mozilla), Rouslan Solomakhin (Google), Sameer Tare (Mastercard), Nick Telford-Reed, Justin Toupin (Google), Laura Townsend (MAG), Arno van der Merwe (Entersekt), Danyao Wang (Google), Clément Warnier de Wailly (Canton), Wanli Yang (Airbnb)


  1. SRC flows
  2. Tomorrow's meeting

Background reading:

SRC flows

[Slides from Mastercard on SRC flows with PR API]

Jonathan: We've had a variety of discussions about how to integrate SRC into PR API. At previous FTF meeting in Japan we looked at some user experience demos.
... today we want to review the technical flows for the integration
... Thanks to lots of input from Chrome team and Ian. I hope we are on the right track. We want to see how to integrate SRC into PR API to see how to enhance the merchant and user value propositions
... one objective is that merchants would like to validate whether SRC credentials are available (via hasEnrolledInstruments)
... dynamic update of total is useful
... One consideration is the role of the browser: namely whether the browser places an active role in SRC or not. The flows should work the same either way.
... that's part of the design consideration.
... Also there are some options for merchants: to display the list of cards before invoking PR API or after.
... we have several flows today: (1) first time consumer (2) Returning unrecognized user ... this is the flow we anticipate will be more common naturally (3) Returning unrecognized user

First time consumer flow

[Tomasz walks through the flow]

Tomasz: There is a Common Payment Handler in this proposal
... the Common Payment handler is the starting point for access to different SRC systems via SRCIs (identified by URLs)
... the Common Payment handler consists of a service worker (for the Payment Handler API) and a Web page
... in this flow the merchant calls Payment Request API with either a single payment method identifier that refers to the SRC payment method or multiple PMIs, one per SRC system. We have not yet decided on the 1 or N PMI model yet. In any cases, even in the design with N PMIs, they would also share a common origin (domain name) in order to allow all of the SRC systems to identify the same Common Payment Handler.
... The payment request data model will (mostly) depend on the EMVCo spec.
... but the input data also includes an SRCI URL
... the idea is that the merchant can specify which SRCI they want to interact with, e.g., a large PSP

Jonathan: Might also be an individual card network acting as the SRCI

Tomasz: The idea here is to have multiple payment method identifiers using the same origin but with paths that refer to specific SRC systems. They will also identify the same default payment handler.
... The merchant in this flow is checking whether a low-friction flow is possible. Merchant uses hasEnrolledInstrument, which returns a boolean (e.g., depending on a variety of conditions specified by the payment method).
... in the first-time user flow, hasEnrolledInstrument (henceforth hEI) returns false.
... I note that per yesterday's discussion, some form of consent is likely to be required to install the payment handler. I think this will not be a problem given the UX examples we've seen.
... Note that depending on evolution of canMakePayment in show(), the flow might change. Another important consideration - because we have a Common Payment Handler, we are talking about a flow where the browser skips the sheet.
... also, the payment handler will register as supporting delegation of request for shipping and other contact information
... this is going to be part of the skip-the-sheet algo (cf yesterday's discussion)

Clinton: When you say "We have a common payment handler." Is there some additional context you can provide around what it is and where it sits in the ecosystem?

Tomasz: The idea is that the common payment handler is provided by the SRC systems collectively, but is not part of any particular SRC system. Or it could be provided by an independent party. One of the reasons for a common payment handler is to facilitate Just-in-Time installation. Security properties of service workers (and not being able to install them cross-origin) are driving part of the design.

Clinton: So you are looking at this from a functional perspective?. Ok, got it.

ian: To frame this discussion further, our goal today is whether functionally it makes sense to use payment handler API
... we haven't looked at who would provide the common SRC PH
... though common entity is anticipated in the SRC spec. In this design the common PH has minimal functionality, namely to redirect the user to the SRCI identified by the merchant
... we've taken this approach to simplify the user experience. This is the proposed architecture, which was driven by some assumptions that we had documented
... these flow diagrams hopefully show how it fits together

stpeter: I encourage folks to join the card payment security task force!
... I have a question that there is an assumption that enrollment will typically happen during checkout.
... have we thought through what this would look like if the user were visiting an issuing bank site or the card network site?
... what would enrollment look like from another site?

Tomasz: I think the design we present would allow for other enrollment scenarios (e.g., network or issuer)

stpeter: Ok, I understand this to mean "there might be other ways to do this"

Tomasz: One of the user experience goals is to reduce app selection
... We don't want to have multiple SRC payment handlers
... so issuers should be able to install the common payment handler if not already installed

ian: one of the UX requirements we documented was to not require the user to first select a wallet (payment handler) then select an instrument. There are a couple of ways to avoid payment handler selection. The first is to only have "the one true handler" in the ecosystem, which is the core of this proposal. Another idea that we are still discussing (for this and other payment methods) is the idea of a "user selected default payment handler" which would allow the browser to skip-the-sheet in some additional scenarios and thus avoid payment handler selection.

<Zakim> ChrisD, you wanted to ask for clarification that common payment handler is always required, even when installed via an issuer's site.

Chris: Clarification question - in this solution, there will always be a common payment handler.
... is that correct?

Tomasz: The assumption here is that the Common Payment Handler should be used to handle SRC payments

[IJ thinks that other handlers COULD work but there is a goal of this particular to have one starting point.]

ChrisD: So you are expecting it will always be installed.

Tomasz: We want there to be no selection in the sheet (of handlers) but rather selection of cards (in the SRCI)
... thus, we are not planning to display cards in the sheet.

Jonathan: We are not trying to reinvent the SRC flow; we are trying to reuse the deployed SRCI logic, but to have a better UX with PR API.

[Resuming at step 13 of first time user flow]

Tomasz: The PH service worker has access to indexDB. We anticipate storing a token that represents an SRC profile for the user.
... so the user is first recognized, and the service worker stores the token for access in future sessions.
... I note also the likely restrictions that browsers will be implementing regarding 3p access (see the 3p storage proposal).
... that is the scenario in which we find ourselves here.
... so we are assuming either user consent or notification to the user in order for the payment handler to have access to this long-lived tokens as the user browses to different merchant origins.
... and the user will grant consent to both (1) allow the payment handler 1p access and (2) install the ph
... The payment handler page does not display UX but hosts an iframe.
... the iframe loads content from the SRCI (designed by the merchant's URL provided in the method-specific data fed to Payment Request)
... the ph page provides data to the SRCI to enable the SRCI to conduct the SRC flows

Gerhard: What happens if the user has 2 cards?

Tomasz: The SRCI solves that.
... in a nutshell, the role of the SRCI (defined in EMVCo spec) is to (1) recognize the consumer and (2) display enrolled cards for selection

Jonathan: The flows that you see here don't change the SRCI functionality (already implemented today)

<Zakim> AdrianHB, you wanted to ask if we can avoid needing the common PH for non-enrollment cases if skip-the-sheet rules changed to support default PH

AdrianHB: I recognize why, during enrollment, it's useful to have a common payment handler.
... but where the user has another payment handler installed that supports SRC, it feels like there is no need to have a common payment handler.

Jonathan: SRC is redirecting a consumer to a list of cards, not a list of banks.
... the goal is to redirect the user to a list of cards.

AdrianHB: Then the DCF could be installed as a payment handler. In short, do we always need these redirects?

<jeffh> rather than a list of issuers

Tomasz: This design proposes a single payment handler for all SRC requests.

AdrianHB: Is the purpose of the common payment handler to facilitate skip-the-sheet?
... I am hearing that as an implementer I would embed something in the common payment handler in an iframe.
... I'm wondering whether the motivation for that is skip-the-sheet.
... if that's the only motivation, then we should reconsider the skip-the-sheet logic
... if we want to allow N > 1 payment handlers and I want to go straight into my issuing bank...

Ian: That's the separate proposal I mentioned regarding "user's preferred payment handler." In a world of N > 1 payment handlers, that's the idea for enabling more skip-the-sheet scenarios (into the user's preferred handler).

AdrianHB: I am trying to understand the design motivation. Is it just to avoid payment handler selection, or are there other design reasons?

Jonathan: We want to leverage N > 1 SRCIs.

<Zakim> ChrisD, you wanted to ask at interaction 20 is the API at the target of this call defined by EMVCo SRC spec? Specifically, I am wondering if there is a way for the Merchant to

IJ: ChrisD asked the question of how the use case of "user has 2 cards" is handled. In the task force we have also discussed additional scenarios. One is "what if the user has two SRC identities?" I think the current proposal supports that use case. The payment handler would simply store two SRC identities in indexDB. The other scenario of note is "what if the user has two SRC identities and doesn't want parties to link them?" For that case, the current recommendation is to use different profiles either at the browser or operating system level.

ChrisD: If you have an ecosystem where you have N > 1 SRC handlers, and you didn't use the common payment handler, isn't there a danger that the user has to choose a payment handler first, and then when you get to the SRCI, you are asked to choose a card?

IJ: Chris, I believe that what you are saying is true -- if we have N > 1 payment handler and no user default, the user will have to make a choice. For that scenario we are discussing the "user preferred payment handler" proposal. One can imagine a UX where the user makes a choice one time, and is given the option, for example, to check a box and make a payment handler the preferred payment handler. The user could change those preferences in browser settings.

ChrisD: At interaction 20 is the API at the target of this call defined by EMVCo SRC spec? Specifically, I am wondering if there is a way for the Merchant to pass in a transaction reference to allow subsequent reconciliation. Most payment service providers (/ payment initiators) will support merchants passing in an MTR.

Tomasz to ChrisD:Payment method definition might define both inputs/outputs and also how an SRCI would integrate with the payment handler that implements the payment method.

Tomasz: SRC defines a transaction id that can be associated with a particular transaction, and that would be part of the payment method specific input data that is handed to the SRC; see our early and incomplete work on a data model for an SRC payment method.

ajay: Is it possible for multiple payment handlers to be displayed in the sheet?

Tomasz: If the merchant specifies more than one payment method, yes. Otherwise if the merchant only uses the SRC payment method identifier, then no.

Ajay: So we can make an assumption that the owner of the origin for that payment method will determine the payment handler ecosystem

Tomasz: Yes

Ajay: Is there an assumption here that the SRC systems don't have to change with this.
... only the SRCI needs to expose a common payment handler, and all the SRC systems behind the scenes can remain as-is?

Tomasz: Our hope is yes; perhaps only with small tweaks
... also DCFs should not have to change

[Resume discussion of flow at step 20]

Tomasz: Long-lived token goal is to bind an instance of the browser to an SRC profile
... The token is issued by one of the SRC systems, but usable by multiple SRC systems
... the payment handler service workers stores the SRC profile token in indexDB
... for subsequent transactions
... and after the user has chosen the card to pay, there is a cascade of data returned to the ph, then to the browser, then to the merchant via Payment Request response. I note that the payment handler has the job of packaging the data that is the SRC response data.

ChrisD: At flow line 22, within the payment request data, would a PSP (if acting as SRCI) be able to specify free-form key-value pairs?

NickTR: It would be my understanding that because the merchant is identifying an SRCI, then what goes into that blob will be interpreted by that SRCI and therefore it can be whatever they agree to privately.

Tomasz: From the payment request API perspective, it's just a blob. It will be up to the payment method definition.

ChrisD: The reason I think it's important to support free-form key pairs: this is a mechanism for value-added services.
... we need a way for the merchant to pass extra data to us.

ian: Is the ability to provide custom data to an SRCI something that we will get for free by importing from the EMVCo definitions?

Tomasz: I don't think this is part of the EMVCO API today
... the SRC spec defines contract between SRCI and SRC System
... there is an allowance for custom data from SRCI to SRC System
... but the requirement here is about the payment method allowing for custom data from merchant to SRCI

ChrisD: So it would be useful to pass SRCI-specific data values through this flow

Ian: Thanks ChrisD for this question/suggestion. (Editor: Added as issue 26.)

Tomasz: We can define the payment method to allow for custom data.

ChrisD: What happens in flow between 26 and 27 in the flow?
... there needs to be a way for the merchant to validate results.

Tomasz: I agree. I have not included the validation on the flow because there are multiple ways to do this. ...eg., we are not showing the option of the PSP (as SRCI) validating the payload

<AdrianHB_> The SRCI URL could hold URL parameters that the SRCi will be able to process when the PH embeds the SRCi iframe (step 21). This would allow any data to be passed from the website to the SRCI.

First time user with built-in support for payment method

Jonathan: We can skip that slide since the same as first, but with built-in support of the payment method by the browser.

Returning Recognized user with third party payment handler

Tomasz: Note in this flow that the merchant calls hasEnrolledInstrument which this time returns "true" because the user is recognized
... the payment handler verifies that it knows of a previously stored token
... the merchant thus calls PR API since low-friction flow is possible.
... Payment Request show() is called, which in turn involves the browser verifying that the user has a registered payment handler
... there is only one, so skip-the-sheet happens
... the browser launches the payment handler, which loads the identified SRCI code and passes data to it. The payment handler also hands the long-lived token to the SRCI. The SRCI queries all the SRC systems whether on of them knows the token.
... then it is translated into a federated ID recognized by all the SRC systems
... and that is used to get all enrolled cards, which are displayed to the user.
... after selection, the data is sent back through the cascade of APIs
... the payment handler packages the data, closes the window, and returns data to the merchant via PR API

NickTR: Is there an underlying assumption that the merchant will use hasEnrolledInstrument to determine whether to display a "click to pay" button?

<jeffh> specifically a SRC pay button alongside _other_ pay buttons

Tomasz: Yes, that's the preferred usage.

Jonathan: It's not a requirement but a choice available to the merchant

NickTR: What will user experience be if the merchant uses multiple PMIs in PR API call?

Tomasz: Right now we only have Chrome as an implementation. The user would see the sheet (or selector of some sort) to choose a payment handler.

NickTR: And what if the Merchant asks for basic card as well?
... we recall that Chrome is deprecating their built-in support for basic card

<AdrianHB> +1 for ANYTHING but basic card :)

[IJ expects good practice documentation on all this, e.g., available from the payment method definition]

Tomasz: We are not preventing other use cases, just setting forth expectations for the desired use case. In this flow, token has been removed from indexDB (e.g., by user clearing local storage, or through some other process)
... the merchant calls hEI which returns false.
... this means to the merchant that it might not be possible to have a low-friction checkout. So a decision point for the merchant.
... in this diagram the merchant is choosing nonetheless to go through PR API
... in this flow, the payment handler is already installed, so it is matched by the browser and invoked via skip-the-sheet.
... after that, the flow is the same as the first-time user
... basically, there is a check for the token...it doesn't exist, so the user is authenticated first.
... the rest is the same (get token, store it for future transactions, get final payload, etc.)

Jonathan: This is just one option of solving for this use case.

NickTR: This would include the case where the user is in a new browser or a computer they've not yet used.

Jonathan: First time user means "first time using this browser"

Tomasz: the checkout flow supports both "add card" and "retrieve enrolled card" scenarios
... "Not recognized" means either (1) Never done SRC before or (2) first time on this browser

Ian: Ajay asked a good question about canMakePayment and hasEnrolledInstrument. Right now there's some confusion in the diagram but that is because there are some spec bugs (or pending updates). Specifically: (1) we want to change the name of the event in Payment Handler API from "canMakePayment" to "hasEnrolledInstrument". Obviously today that is confusing. (2) the expectation as I understand it is that for canMakePayment, browsers will not consult payment handlers, whereas they will for hasEnrolledInstruments. That's not reflected today in the definition of show() in Payment Request API. The expectation is to modify Payment Request API so that it becomes clearer that the browesr does not invoke hasEnrolledInstrument during show(). That will simplify Tomasz's flow diagram. See also the proposed clarifications around payment handler availability.

NickTR: Many thanks to the networks and browser folks for getting us to this point.

IJ: Please feel free to raise issues on the GitHub repo. There are some things in today's presentation that are new thinking. We are pursuing consensus approaches. Please raise issues if you have questions or doubts.

Tomorrow's meeting

NickTR: Focus on authentication.
... but first making up time on one more payment handler proposal
... but then update from the WebAuthn WG
... and then some discussion about the task force discussion
... and then we'll hear from STET as a preview of open banking discussion on 2 April

IJ: Thanks Tomasz and Jonathan!!


Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/04/07 14:59:12 $