Background reading:
[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
[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.
Jonathan: We can skip that slide since the same as first, but with built-in support of the payment method by the browser.
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.
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!!
[Adjourned]