[DRAFT] Web Payments Working Group Charter

Scope

A payment, on the Web today, ordinarily starts on a payment page where the payer must manually select a payment scheme , manually select their own payment instrument for that payment scheme, manually capture the details of that instrument into the page (along with any other essential data such as a shipping address) and then submit this data back to the payee. The payment data briefly passes through the Web (from the payer's user agent to the payee's server) on its way to a payment processor. At that point, much of the communication to complete a payment takes place among banks, card networks, and other parties in the payment ecosystem typically outside of the Web.

Various parties have innovated ways to simplify this flow, for example by caching payment instrument information in browsers, registering users on eCommerce websites to facilitate re-use of customer data and/or payment credentials (increasingly through the use of tokenization), and even developing new payment schemes. Unfortunately, these efforts suffer from a lack of standardization in areas such as:

• the high level flow of a Web payment;
• the programming interfaces between the various parties (such as between user agent and Web application);
• the messages exchanged between these parties over the Web.

The result is that users are led through entirely different flows deleted text: and verification routines every time they make a payment on the Web.

To reduce this fragmentation, this Working Group will create open Web standards for the programming interfaces in and out of the Web context. This will increase interoperability between payer and payee systems (for existing and future payment schemes), and encourage greater automation of the steps in a typical payment. The programming interfaces between the payment schemes and the Web are usually at the user agent and the Web application, therefore the scope of the initial charter is focused on the interactions between these two components and the external actors that will interface directly with them. Note: These standards may also prove useful in a "native" application context, but this group is not focused on that use case.

The group will focus primarily on standardisation standardization of a set of messages and a message flow for the initiation, confirmation and completion of a payment. By focusing on the message format and flow, the group leaves open the standardisation standardization of the delivery mechanism for these messages as this will vary depending on the use case and technology stack. To support use cases where messages are proxied between payer and payee using different technologies, the group will standardize delivery mechanisms for common scenarios. This will include WebIDL APIs for the use cases where the messages are proxied between payer and payee via a Web browser or Web APIs where the messages are exchanged directly over the Web between two online entities in the classic REST pattern.

Note: This group is chartered to standardize programming interfaces; not user interfaces.

For more information about Web Payments activities beyond the scope of this charter, see the Web Payments Interest Group description below.

Payment Flow

The scope of work supports the following elements of a basic purchase triggered by payment initiation through a Web application. These standards define a high-level message flow for a payment from payer to payee either in the form of a credit push (payer initiated) or a debit pull (payee initiated) payment, and can be used to facilitate a payment from any payment scheme. They involve:

Pre-Payment

• Registration , by the payer with their wallet , of any conforming payment instrument they wish to use on the Web (a credit or debit card, electronic cash, cryptocurrency, etc).

Negotiation of Terms

• Payment Initiation Request , by the payee to the payer providing the terms of the payment including elements such as the accepted payment schemes, price, currency, recurrence, transaction type (purchase, refund, etc.), timeout and requests for any additional data that is required from the payee.

Negotiation of Payment Instruments

• Discovery , by the payer, of their available payment instruments that can be used to make the payment. This is done by matching those registered by the payer with those supported by the payee (as defined in the Payment Initiation Request), while keeping information local to the payer.
• Selection of a payment instrument by the payer, confirmation of the terms, and sending of any requested data back to the payee for validation.

Payment Processing and Completion

• Execution of the payment by either payer or payee.
• Delivery of a Payment Completion generated by the entity that executed the payment. This may contain a Proof of Payment if supported by the payment scheme.

<img src="images/WebPaymentsBasicPaymentFlow.png" alt="Web Payments Basic Payment Flow"/>

The group will also address exceptions that may occur during these steps, including payment authorization failure.

Security and Privacy Considerations

Security is obviously critical in payments. While the initial work of the group will leave much of the required security and authentication (e.g., encryption and digital signatures) to payment schemes, it is important to ensure that any additions to the Web platform are secure and tamper-proof. The ability to manipulate any message in a payment flow has potentially massive financial impact. Therefore the ability to prove message integrity and verification authentication of all message originators should be a key consideration for any work done by the group.

W3C is planning to charter other The Working Groups to develop standards, covering topics such as security, that Group will be important consider how existing payment schemes address security requirements. In addition, W3C is developing additional security-related specifications in facilitating payments on the Web. The current other groups. This Working Group will follow that work to help ensure compatibility with the payment flow standards produced by described in this Working Group. charter. In particular, this group will may consider how the role of hardware-based solutions may be used to generate and store secrets for secure in securing transactions, and how the role of hardware devices may be used to verify a user's authenticity in authenticating users via biometry or other mechanisms.

Protection of the privacy of all participants in a payment is essential to maintaining the trust that payment systems are dependent upon to function. Any payment process defined by the group should not require disclosure of private details of any of the participants' identity or other sensitive information without their explicit consent. The design of any public facing API should ensure it is not possible for guard against the unwanted leakage of such data deleted text: to be leaked through exploitation of the API.

Relation to Wallets

The standards from this group may be implemented in a variety of ways, including within stand-alone Web or native applications, within applications in the Cloud, within user agents such as Web browsers, or in the form of user agent extensions or plug-ins. Some of the capabilities provided by the standards from this group can be found in today's digital wallets and various other Web services. Because the "digital wallet" concept is useful as a shorthand, but means different things to different audiences, this charter includes the following definition to clarify the intent of this group.

In this charter we define a wallet as a software service, providing similar functions in the digital world to those provided by a physical wallet, namely:

• It holds and allows access to payment instruments registered by the payer.
• It provides logic to support certain payment schemes and enables the payer to use registered payment instruments to execute a payment in accordance with the rules and processes of that scheme.
• It may hold digital assets, in the form of one or more account balances, that can be used to make payments.
• It may enrich the payment flow by implementing business logic for loyalty, coupons, ticketing or other function that is complimentary complementary to its payment capabilities.

This group is not developing standards for all digital wallet capabilities: this charter's scope is limited to payment flow capabilities. At the same time, this definition of wallet is not intended to constrain W3C's future activities. Indeed, W3C anticipates a rich ecosystem of eCommerce and payment functionality on the Web, including loyalty schemes and coupons, digital receipts, digital credentials, location services, marketing additions, and more. Some of this functionality may be provided by a digital wallet, or by other services available to the payer. This charter does not seek to preclude those additional services, and in the future W3C may look for opportunities increase the interoperability of such services. The wallet metaphor appropriate to this charter may change in future charters or may be dropped if no longer relevant.

This Working Group intends to create a standard interface from the Web to a payer's wallet so that someone with any a conforming wallet can seamlessly make payments with any a conforming application running in a conforming user agent. The group may define APIs that will also be used outside of a user agent context (such as between Web services, or from within a native application, where the browser is not the proxy between wallet and payee application).

On Multiple Wallets

In the design of these standards, the Working Group will not assume that each user has only one wallet. In this charter, the phrase "the payer's wallet" is shorthand for "the payer's wallet(s)" as the payer may have multiple wallets.

The Working Group may consider the use case where an aggregation service acts as a more sophisticated wallet service or providing provides a wider choice of payment solutions to the payer. For example, the aggregator service might combine the functionality of multiple wallet services, or apply more complex algorithms to discover and collect the set of payment instruments available to the payer.

Out of Scope

This group will not define a new payment scheme, or redefine that which is already addressed today by payment schemes. The standards from this group will provide a channel for protocols and messages defined by payment schemes.