SRC and Payment Request Integration

Candidate Flow Diagrams

Notes:

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.

SRC Enrolment

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)

Transaction

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 the section 3.1 of 3-D Secure 2 with Payment Request API for more discussion.

Identity Management

SRC systems include a notion of cardholder identity. The following diagrams illustrate different identity management scenarios.

In each diagram below, there is only a single payment handler available to the user.

New User

Single Payment Handler; Add new card to a device; first time use of payment handler

Returning User to Same Device

Single Payment Handler; Repeat purchase experience on same device

Returning User to New Device (without identity known to payment handler)

In this flow, a user with an existing identity is using a new device for the first time. The payment handler does not know about the user's existing identity and so the user's experience is that of adding a new card to the SRC system(s). The payment handler generates a new identity for the user based on device characteristics.

Single Payment Handler; Returning User; First Time use of another device; payment handler relies on device characteristics to establish identity.

Returning User to New Device (with identity known to payment handler)

In this flow, a user with an existing identity is using a new device for the first time. The payment handler knows about the user's existing identity, so it retrieves previously enrolled card information from the SRC system(s).

Single Payment Handler; Returning User; First Time use of another device; payment handler knows about user identity.

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 manifests.
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 ecosystem.
The payment handler registers card metadata with the browser (see the PaymentInstrument dictionary).
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 detail.
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 manifest.
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 src or 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) BobPay and src.
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.