The purpose of this page is to document assumptions, requirements, and desired behaviors during SRC user journeys. This page does not represent consensus and is intended to inform the development of an SRC payment method and accompanying user experiences. Questions? Ian Jacobs ij@w3.org.

As part of designing an SRC experience with the Payment Request ecosystem, we have been considering not just the data requirements of an SRC payment, but user journeys in detail. It seems useful to distinguish two main user experience scenarios:

• The user has zero SRC Payment Handlers
• The user has one or more SRC Payment Handlers

One the user has an SRC payment handler (DCF), as documented in the assumptions below, the user should be able to add cards to SRC, select from enrolled cards, and pay with them.

How does the user get their (first) SRC payment handler? We have discussed multiple approaches:

• While browsing on their issuing bank site, the bank silently registers a payment handler that can be used at the next transaction (through PR API).
• The owner of the SRC payment method publishes a payment method manifest that identifies one or more payment handlers.
• The browser knows (out of band) about payment handlers and offers the user a choice; see this blog post on browser-default payment handlers.

All of the above would work with all payment methods (not just SRC). The first two work today in Chrome; the third would require some changes to Chrome.

However, based on discussions with SRC stakeholders, no option above suffices on its own.

The purpose of this document is to get a better shared understanding of assumptions and requirements to see whether there are any other approaches that could facilitate procurement of the user's first SRC payment handler.

There exists a unique mapping from BIN to SRC system that is discoverable by a piece of software (e.g., a DCF).

FOR REVIEW: There is some disagreement and/or confusion about this point; SRC system providers should clarify.

Based on 13 November 2020 discussion, we should not assume that every SRC payment handlers will be able to enroll every card into its corresponding SRC system. As an example: a payment handler may be able to enroll Visa cards (into the Visa SRC system) but not Mastercard cards (into the Mastercard SRC system).

Based on 13 November 2020 discussion, we should not assume that every SRC payment handlers will be able to display cards (for selection) from every SRC system. As an example: a payment handler may be able to display cards from the American Express SRC system but not the Discover SRC system.

Initially we had understood that there were some practical, technical, and regulatory reasons why SRC systems might not be able to publish a common payment handler.

However, it seems (as of March 2020) that the ecosystem might support a Common Payment Handler with limited functionality, namely redirecting the user to an SRC-I identified by the merchant in the call to Payment Request API.

A user should not be required to know what SRC system a card would be enrolled in. Therefore, we should not rely on payment handler enrollment experiences that rely on the user knowing and selecting the relevant card network payment handler (e.g., by card network logo).

A user should not be required to visit their issuing bank's site in order to enroll their card(s) in an SRC system.

Because of the previous assumption, add card functionality will involve the user entering a PAN.

A user-side entity therefore needs to identify the relevant SRC system based on a PAN. Because there is not likely to be a universal payment handler for this function from SRC systems, and because of the assumption that payment handlers may not interact with all SRC systems, this creates challenges.

One idea: the user agent —or "thin" payment handlers known to the user agent— could provide a discovery functionality. The user would enter a PAN, leading ultimately to installation of a relevant payment handler capable of enrolling that PAN, authenticating the user, and other aspects of SRC flows.

This will have an impact on user experiences such as authentication. (See Storage Access API.)

The user experience must always provide a way to either add a card or pay with a previously enrolled card.

See related blog post on browser-default payment handlers.

Users must be able to select an instrument for payment without an intermediate step of selecting from a set of available SRC payment handlers (wallets). Because of some assumptions listed above, the consumer may forget which card is in which wallet and choose the wrong one. This is a bad user experience.

In the case of one registered payment handler, skip the sheet fulfills this requirement. Browsers could also provide "skip the sheet" functionality when the user has more than one payment handler for a given payment method (and the user would change the default in the browser settings). This is how search functionality in the browser works today.

A sheet that displays instruments and allows their selection (launching the responsible payment handler) fulfills this requirement.

Based on 13 November 2019 discussion, "no wallet selector for SRC" includes the use case where the user has not yet installed any SRC payment handlers. That is: prompting the user to select one from among multiple wallet options is not an acceptable user experience to bootstrap the ecosystem. One concern that was raised was: what if the user tries that payment handler and then decides to try another one. The concern was about the cognitive load of having to remove a payment handler and then choosing a different one from among multiple options.

A payment handler may support access to one or more SRC systems. Once the payment handler has established a user identity with one of the supported SRC systems, the user should not have to revalidate identity across any of the SRC systems supported by the payment handler, for some period of time.

We have discussed three requirements related to user identity: persistence of information, no exfiltration, and no user gesture upon return.

Minimize the need to enter the identifier (email) used to access SRC systems.

• Display instruments in the sheet. Currently supported by Payment Handler API but not implemented.
• One instrument per payment handler. Rouslan recommended this approach as a way to display card art directly in the sheet. This would satisfy the "No wallet selector" requirement and would not require any changes to Chrome.

Today Chrome implements a skip-the-sheet functionality under certain conditions.

There are ways to increase the opportunities for skip-the-sheet. The user can indicate to the browser a preferred payment handler for the case where the user has more than one payment handler. The definition of “preferred” means that any time the merchant accepts a payment method supported by this payment handler, the user wishes to pay with this payment handler. How the browser displays the preferred payment handler (e.g., as a default option) is implementation specific.

If the user has not yet identified a preferred payment handler, when the browser displays multiple handlers to the user and the user selects one, the browser offers the option of making it the preferred payment handler. The user can change preferences in the browser’s usual UX (as users do today with search engine preferences).

Result:

• No Wallet Selector. Once the user has identified a preferred payment handler, in conjunction with skip-the-sheet this would eliminate wallet selectors for the case where the user has at least one payment handler for at least one payment method accepted by the merchant.

Each SRC system mints its own payment method identifier. Merchants that accept payment from networks A and B would refer to both SRC systems (via URLs) in their calls to Payment Request API. Each SRC system's payment method manifest could refer to the same default payment handler. It should be possible to identify a different default payment handler depending on architecture (e.g., Android with Chrome, etc.).

Result:

• User Must Have Path to Use a Card: Just-in-time installation based on payment method manifest instructions. Distributed management of payment handlers.
• No Wallet Selector. Where there is agreement on the default payment handler, the user would not face a wallet selector.

This was originally discussed in a blog post.

• User Must Have Path to Use a Card: Just-in-time installation based on out-of-band browser knowledge.

Rather than imagining a monolithic SRC payment method, it may be useful to distinguish functionality in two payment methods: one for discovery, one for payment. This might enable different parties in the ecosystem to provide thin front-ends to a set of SRC systems.

The idea here is that some party (or more than one party) could distribute a payment handler capable of the following:

• Accepting PAN input from the user
• Identifying the relevant SRC system
• Redirecting to that SRC system (or otherwise invoking that system). This could result in installation of a payment handler capable of interacting with that SRC system and carrying out other SRC functionality (such as display of instruments, fetching a token, etc.). The payment handler might be registered with a single instrument (per the "one card per payment handler proposal").

• Ian thinks part of the answer is "service workers"
• But there is also an idea of show() triggering an event in payment handlers to refresh their list of instruments.

• For example, the discovery payment handler could first prompt the user to enter (or get from the ecosystem) their SRC identifier.