This is a (draft) description of the flow enabled by the W3C's Payment Request API (described in part in the Web Payments Overview). The goal of this description is to provide enough information about the flow at a high level that regulators will be able to draw W3C's attention to potential regulatory issues that either user agent implementors or users of the APIs may face.

Note: It is not a goal of this effort to influence public policy or regulation. It is only a goal to ensure that W3C's deliverables are consistent with regulatory expectations. In addition, this is an informative summary; please see the relevant specifications for normative language.

Todo:

• Include links from flow description to relevant specifications.

Question? Please contact Ian Jacobs <ij@w3.org> and cc the Web Payments Interest Group mailing list <public-webpayments-ig@w3.org>.

Terminology

• A payer (e.g., consumer) wishes to make a payment to a payee (e.g., a merchant) on a Web site.
• The payee accepts any number of payment methods. A payment method is characterized by the data that the merchant provides to the payer and receives from the payer in order to be paid.
  • Example: For a basic card payment method, the merchant provides no data to the payer and receives from the payer card number, expiration date, etc.
  • Example: For a credit transfer payment method, the merchant provides information about the merchant account, etc. and receives from the payer information about processing date, transaction codes, etc.
• The payer uses software to make a payment; we call this software a "payment handler." A payment handler may support one or more payment methods. payment handlers may be implemented using a variety of technologies, including those of native operating systems or Web technologies, or a hybrid. Browsers may also act as payment handlers, storing user credentials such as card information. The Payment Request API and Payment Handler API do not address the internal workings of payment handlers, only how they communicate with the user agent.
• The user registers payment handlers with the user agent. This amounts to telling the user agent which payment methods each payment handler supports.
• Some payment methods are "proprietary" in that a business entity defines the data required for that payment method and authorizes parties to implement the payment method in a payment handler. In many cases, the entity that owns the payment method may be the only entity that distributes a payment handler for that payment method.

Flow Summary

Scope

• W3C's specifications focus on the user experience of making a payment, and the way that payees build checkout experiences on the Web to initiate payment. W3C's specifications do not address all aspects of the payment ecosystem.

Before a Transaction

• For most payment methods, the payer enrolls (sets up an account) with various payment service providers. This includes setting up a card account, online payment service account, bank account, distributed ledger wallet, etc. The payer then provides credentials to payment handlers (both browsers and third-party payment handlers) and registers those handlers with user agent(s) that support the API.
• The payee builds a checkout experience using the W3C API instead of a Web form. Note that the payee may delegate part of the checkout experience to its service providers. Indeed, the payee may never see payment response information that is sent directly to its service providers. In the description below, we simplify by referring only to the payee. The APIs do not change how merchants and their payment service providers relate.

During a transaction

• The payer pushes the "buy" button on the payee Web site.
• The payee Web site invokes the Payment Request API, with information about accepted payment methods (such as the basic card payment method) and transaction details (e.g., price, currency, items being purchased).
• The user agent (typically a browser) computes the intersection of payment methods accepted by the payee and those supported by the payer's payment handlers. The Payment Method Identifiers specification discusses payment method identifier syntax and matching.
• The user agent displays to the payer (in native browser chrome) the list of payment handlers that can be used for transaction (because they implement the intersection of payment methods). The Payment Handler API specification defines how Web-based payment handlers participate in this flow.
• The payer selects one to pay.
• The user agent provides transaction details and payment method-specific data from the payee to the payment handler. The user agent then delegates control to the payment handler.
• The payer interacts with the payment handler. payment handlers will vary greatly in the kinds of user interactions they support, for example, whether and how they support authentication, what services they offer in addition to payments, and the user experience optimizations they provide.
• When payee interaction with the payment handler completes, the payment handler communicates response data back to the user agent, including data specific to the payment method and status information.
• The payment handler is closed and returns control to the user agent.
• The user agent returns the payment handler response to the payee.

Flow Specifics

• In the OLD/NEW comparisons below, note that NEW means "how you would do this using payment request API." The OLD approaches remain available.

User Enrollment with Payment Service Providers

• OLD: People sign up for accounts with payment service providers.
• NEW: Same.

Notes:

• Enrollment happens outside of flow covered by W3C's APIs. For example, payment handlers are likely to provide enrollment capabilities that are built using other Web technologies, including backend servers.

User Agent Storage of Credentials

• OLD: Some browsers store credentials (cf Autofill).
• NEW: Same, except that the mechanism for capturing credentials and presenting them for reuse will be more structured.

Notes:

• User agents are responsible for secure storage of credentials today; that will continue
• User agents do not provide information about stored credentials to merchants except through user consent; that will continue.

Payment Handler Storage of Credentials

• OLD: payment handlers store credentials.
• NEW: Same, except that the mechanism for capturing credentials and presenting them for reuse will be more structured.

Merchant Storage of Credentials

• OLD: Merchants use a variety of mechanisms to store credentials, or delegate that to third parties.
• NEW: Merchants no longer need to store user payment credentials in order to achieve a streamlined experience. They may store credentials (e.g., for subscription purposes) but the API offers an opportunity to eliminate credential storage.

Merchant Knowledge of Payment Handlers

• OLD: None, unless merchant is also a payment handler distributor.
• NEW: Very limited, unless merchant is also a payment handler distributor. Merchants can query the user's environment to find out if there is "some way to pay" for a particular payment method using the Payment Request API (see the canMakePayment() method).

User Agent Knowledge of Payment Handlers

• OLD: Browsers do not have a standard way to know about which payment handlers the user has, nor which payment methods the payment handlers support. (People may have used JavaScript libraries.)
• NEW: Users have a standard for letting browsers know about payment handlers and which payment methods the payment handlers support.

Display of Supported Payment Methods to the User

• OLD: Merchants display information about accepted payment methods in a Web page. Browsers have access to that information via JS APIs.
• NEW: Merchants declare accepted payment methods in JS code. Browsers have access to that information via JS APIs. Browsers display to the user the payment handlers that support relevant payment methods.

Payment Handler Communication of Credentials to User Agents

• OLD: None. (I think payment handlers communicated directly to merchants.)
• NEW: JavaScript API. Credentials are then communicated by the browser to the merchant.

User Agent Communication of Credentials to Merchant

• OLD: Web Form (then, for example, HTTP POST)
• NEW: JavaScript API (then, for example, XMLHTTPRequest). In addition, payment handler may communicate with servers.

Merchant Communication with Payment Service Provider

• OLD: The merchant establishes a relationship with one or more payment service providers. Data received from the browser is returned either to the merchant or directly to the merchant's payment service provider, which then uses relevant backend processes for payment processing,.
• NEW: Same. Our API changes how browser sends information to the merchant side, but does not change how it is processed.

Themes

These are themes likely to be common to many regulatory jurisdictions that are relevant in thinking about the W3C payments flow.

NOTE: See also themes listed by Jean-Yves.

Consumer Protection

Security

• Information between parties is secured using standard Web protocols (including TLS).
• Security within a Web page or within a payment handler is the responsibility of the owner of the page or app. Security features such as encryption, and strong authentication (e.g., biometrics, multi-factor authentication) are defined outside of W3C's payment APIs. Numerous W3C groups are developing Web standards to improve Web security generally; these features will also make Web payments more secure. These include strong authentication, digital signatures and key management, and other Web app security topics.
• Secure credential storage is outside the scope of our API. Software will use a variety of means to store information securely, including using operating system primitives, secure hardware, cloud storage solutions, and browser-specific functionality.
• Individual payment methods may enhance security, such as supporting tokenization or encryption of data with key exchange.
• It is our belief that AML and KYC requirements are addressed outside the scope of the Payment Request API. Where AML/KYC requirements demand specific data, payment methods may be devised to address those information requirements.

Privacy

• The API is designed so that only the information necessary for a given party to fulfill its role is available to that party.
• The API may increase user privacy because it is more likely that only necessary information will be sent to the merchant, rather than the merchant collecting additional information via a traditional payment form.
• Users consent to:
  • Make a payment
  • Allow the user agent to share information about the user with the merchant Web page.
  • Provide credentials to a payment handler
  • Register a payment handler
  • Permit a payment handler to return credentials to the merchant

Openness

Open Ecosystem

• Payment Request API can be used with any payment method (at least by design).
  • This includes pull and push payments.
• Anyone can publish a new payment method
  • Payment methods may be identified with URLs.

Notes:

• W3C specifications play no role in determining which payment methods a merchant chooses to accept.
• W3C specifications play no role in determining which payment handlers a user can adopt.
• W3C specifications play no role in determining how various parties fulfill their existing contractual obligations.
• The payment methods that a given payment handler can support do not depend on W3C specifications. Instead, various agreements negotiated out-of-band will determine supported payment methods.

Relation to Messaging Standards (e.g., ISO 20022)

• Payment Request API primarily addresses the user experience of choosing a way to pay.
• Payment Request API does not involve the construction of messages that circulate within payment systems. That remains the responsibility of payment service providers.
• Most of W3C's work is not directly affected by, nor does it directly affect, message standards such as ISO 20022.
• Payment methods determine what data flows through the standard API: what data merchants send to payment handlers (via the browser) and what response data payment handlers return to the merchant (via the browser). As is the case today, with the new W3C APIs payment service providers are responsible for transforming data received after user interaction into messages and formats used on the backend by different payment systems.
• We are endeavoring to align the names of data fields in these specification with relevant industry standards to facilitate understanding.

Open Standards Process

• Anyone may join W3C
• All specifications are public and available at no cost
• The W3C process includes ongoing public review
• W3C has a Royalty-Free patent policy for implementers of the specifications
• Adoption of specifications is voluntary; W3C has no enforcement authority
• For more information on W3C's views on standardization, see Open Stand

Regulatory Notes for Different Parties

Note: Some of this may appear in the future in the developer portal.

Web Payments WG and Implementers of the API

API Users / Web Developers

• AML requirements in some jurisdictions may impose limits on the amount of money that can be transferred via the API.
• Vincent: in some jurisdictions, contracts must be registered before initiation of payment.

Payment Handler Developers