SRC and Payment Request Integration
Candidate Flow Diagrams
- The browser may be a payment handler that implements various SRC functions. In particular, if the browser acts as an SRC-I, it might have access to all cards registered by the user in the SRC ecosystem, even though that may have been enrolled through other DCFs.
- There may be interactions with multiple SRC systems.
- Not shown: Whether and how SRC systems integrate with one or more DCFs for CustomerProfile information.
Note: This diagram shows one way a user can enrol a card in the SRC system through a payment handler. A card may be enrolled through other channels (e.g., a Web site) or by other roles (e.g., a bank acting as a participating issuer).
SRC Card Metadata Registration with Mediator (Browser)
Notes on EMV® 3-D Secure (3DS)
Risk analysis will likely play a role in every transaction. 3DS
may play a part in risk analysis that happens
during an SRC flow. If it does, it make take place at at
various times, including "during Payment Request" or
"after Payment Request."
The diagram above illustrates a flow where the merchant may
request that 3DS be part of the Payment Request flow. There
is still work to be done to define an interface for
merchants that supports a variety of use cases. See
3.1 of 3-D Secure 2 with Payment Request API for more
Payment Method Ideas
- Each SRC Programme publishes its own payment method manifest with N
supported_origins and no
default_applications. This allows each SRC Programme to
manage its own certification program and publish the results in a way
that is machine readable by the browser. This does mean that SRC
programmes will need to work with browsers to add support, but the
initial number should be small.
- The payment method identifier is
'src'. This is easier
for developers, and enables merchants to accept payments from multiple
SRC programmes without changing their front-end integration.
- Each brower (internally) maps 'src' to each of the SRC programme
- As with Basic Card, we would likely include a
supportedNetworks capability filter to improve the chances of a successful match.
- The token info may be an identifier or the token+cryptogram. When token+cryptogram is returned in the Payment Request response, it will be encrypted.
Third-Party Payment Handler Ideas
Aggregation and display of SRC-enrolled cards by the browser/mediator
- An SRC payment handler also acts as a Digital Card Facilitator
(DCF) for the purpose of the user enrolling a card in the SRC
- The payment handler registers card metadata with the browser (see
- The browser can display instrument-level information directly in
the sheet, and communicate to the user the responsible payment
handler. Although there are no Payment Handler API implementations
today that do so, we have discussed this in the past.
- Thus, the browser displays the aggregate of the SRC-enrolled
cards, for those payment handlers that the user has. The browser does
not display SRC cards enrolled through DCFs that are not yet
registered payment handlers. An alternative, of course, is for
browers to implement the CustomerProfile method of SRC for cards
stored directly in the browser.
Just-In-Time Registration for an open payment method
- Of course, users may manually register SRC-enabled payment
handlers at any time by visiting the payment handler origin. Browsers
need to evaluate manually registered payment handlers to ensure they
are authorized; how and when that occurs is a brower implementation
- Just-in-time (JIT) registration (as implemented in Chrome)
happens when the user does not yet have at least one payment handler
for a given payment method. This is useful for bootstrapping payment
method support for the user.
- Chrome can choose a payment handler from the
default_applications specified in a payment method
- We imagine multiple SRC programmes with multiple payment method
manifests, so we recommend another approach.
- First, the brower can show the user the (aggregated) set of
authorized payment handlers for
src. Once the user has
selected a payment handler, it is registered and there will be no
further JIT registration.
- Because the set of
src payment handlers may become
large, it may be desirable to offer mechanisms to reduce the size of
the set. Some of these mechanisms may occur outside the scope of the
standards (e.g., the brower may have relationships with payment
handler providers or SRC programmes). Some of these mechanisms may
involve standardized APIs (e.g., we might enable merchants to specify
a list of preferred payment handler origins for
other open payment methods).
Asynchronous Payment Handler Activities
- Web-based payment handlers use service workers. These service workers should be able to asynchronously communicate with SRC programmes for updated enrollment information.
- Payment handlers might perform SRC actions such as SRC InitRequest at different times (as long as they are licensed by the SRC specification). For example, a payment handler might do background updates after a canMakePayment event as an optimization in case the user selects that payment handler for the transaction.
Ecosystem of Payment Handlers
- Some authorized payment handlers may be payment handlers that
support their own payment methods. Thus, a payment handler might
support both (the fictional example)
- We will need to get a better understanding from various payment
method owners ("*Pay") whether they would be willing to do this.
User Experience notes
- Will it confuse the user if the user sees only cards enrolled through registered payment handlers instead of all the cards the user has enrolled in SRC? This is relevant in particular for users that users re-use an identifier (e.g., email address) for all their cards.
- Todo: Flesh out optional authentication that might happen after card selection and before the SRC PayloadRequest.
- Nick Telford-Reed, Matt Saxon, and Danny Russell for the SRC / PR API evaluation.
- Rouslan Solomakhin for the idea of internal mapping of an
src string to multiple payment method manifests.
- Jonathan Grossar, Jalpesh Chitalia, Manoj Kannembath for additional detailed flow discussions.
2018 W3C® (MIT, ERCIM,
Keio, Beihang). W3C liability,
and permissive document license rules apply.
Last modified: $Date: 2019/02/07 18:55:37 $