STATUS: This is a draft for discussion within the Web Payments Interest Group.

Web Payments Architecture Working Group Charter

Introduction

The mission of the Web Payments Working Group is to make payments easier and more secure on the Web.

• Proposed FTE: .5
• Proposed end date: 31 December 2017

Goals

Under this initial charter, the Working Group defines standards that ease integration of the payment ecosystem into the Web for a payment initiated from a Web site or Web application. Where practical the standards will be usable by native applications/apps.

We anticipate the following benefits of this work:

• A reduction in the percentage of payments that are abandoned prior to completion due to a streamlined payment flow (less work for users to provide information to make a payment should increase conversions)
• Increased customer satisfaction due to additional payment options available to users
• Improved security and privacy by providing information only to those parties that require it to complete a transaction
• Easier for payment service providers to integrate new payment schemes and thereby increase merchant acceptance
• Increased scope for digital wallet innovation by banks, retailers, mobile operators, card networks, and other wallet providers
• Added value through machine-readable digital payment requests and payment responses

The W3C is also planning other Working Groups to develop standards that will facilitate payments on the Web, including stronger authentication, hardware-based security, and identity and credentials.

The Web Payments Interest Group is expected to provide more detailed technical input to the Working Group based on a detailed analysis of the relevant Web Payments Use Cases.

Scope

The pattern of interactions on the Web today is one of clients (User Agents for the most part) and servers hosting Web applications. In a payment interaction these software components are acting on behalf of payers and payees but are part of a larger system defined by the payment scheme they are using and the interaction between the majority of the system actors in a payment scheme happens outside the Web context.

In reality almost no part of the payments process today occurs within the same Web context where the process is initiated or completed. A payment on the Web today, normally starts on a payment page where the payer must manually select a payment scheme, manually select their own payment instrument for that scheme, manually capture the details of that instrument into the page and then submit this data back to the payee. The payment data briefly passes through the Web context (from the payer's User Agent to the payee's Website) on it's way to a payment processor.

To achieve it's goals the group must standardize the interfaces in and out of the Web context providing interoperability between systems and allowing the various manual steps in a typical payment to be automated. However, the group must recognize that the Web's role in any payment today is simply as facilitator and channel for protocols and messages that are defined by the payment schemes. The initial scope of work for this group will be to work within those boundaries and only standardize on things that are re-usable across payment schemes.

The interfaces between the payment schemes and the Web are via the User Agent and the Web application, therefor 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.

On the User Agent side of the Web context is a human providing input into the browser. However, to truly impact the way payments are done on the Web, it will be necessary for the human to be replaced with a software component (stand-alone, cloud-hosted or even built into the User Agent) that can automate many of the manual steps human users are forced to do today. Most refer to this service today as a digital wallet.

Wallets

The term wallet is interpreted in a variety of ways in a digital context however the wallet is a cornerstone of the initial work being undertaken by the group and therefor it is critical that it is defined properly up front.

For the sake of this charter a wallet is defined as a software service, providing similar functions in the digital world to those provided by a physical wallet, and it's holder, in the real world.

• A wallet holds payment instruments that were registered by the wallet owner
• A wallet has built-in knowledge of certain payment schemes and how to use it's registered payment instruments to execute a payment in accordance with that scheme
• A wallet may hold one or more balances of some digital asset that can be used to make payments

The group will aim to standardize the interface from the Web to a user's wallet such that a user with any conformant wallet can seamlessly make payments with any conformant Web application running in a conformant browser. The group should define these standards in such a way that they will be usable even in scenarios where the User Agent is not the proxy between the payer wallet and payee application (i.e. The messaging can be re-used for native apps and the browser is not in the critical path).

The goal of the group must be to create a standard that promotes fair competition between vendors of wallet software. To ensure that neither browser vendors nor payment schemes have an unfair advantage it should be possible to define a wallet that is an aggregator of other wallets. This prevents proprietary payment scheme functions being built into wallets as a means to force users to use only that wallet.

Payment Flow

The scope of work supports the following elements of a basic purchase triggered by user interaction with a Web application initiating a new payment. The work of the group is to standardize a high-level message flow to facilitate a payment from payer to payee either in the form of a credit push (payer initiated) or a debit pull (payee initiated) that can be used to facilitate a payment from any payment scheme.

Pre-Payment

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

Negotiation

• Payment 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.) and requests for any additional data that is required from the payee.
• 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 Request).
• Selection of a payment instrument by the payer, confirmation of the terms and sending of any requested data back to the payee for validation.

Processing

• 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.

For more information about roles involved in this payment flow (payer, payee, etc.), please see the Web Payments Interest Group's glossary.

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

The scope is expected to increase over time to support a wider variety of ecommerce scenarios; loyalty programs and coupons; peer-to-peer payments; and harmonization of user experience in-browser, in-app, and in-store. For more information, see the Payments Use Cases published by the W3C Web Payments Interest Group.

Deliverables

Recommendation-track deliverables

Web Payment Vocabularies 1.0

The Working Group will develop vocabularies that enable the following:

• Payment Scheme Description: this vocabulary is used by payees to represent accepted schemes, and by payers to represent their available payment schemes and instruments.
• Payment Term Description: used to define the terms requested by the payee prior to payment initiation. It includes information such as amount, currency, payee account information, recurrence, transaction reference and any scheme specific data that is required.
• Proof of Payment: a verifiable payment authorization from the account provider to the payee. The proof must include information about the payment request (a transaction reference or similar) and the payer's payment instrument.

Notes:

Do we need these notes in the charter?

• We anticipate that URIs will be used to identify payment schemes. In this charter we do not anticipate creating a registry for payment scheme identifiers.
• Records using these vocabularies must be tamper-evident.
• It will be necessary to be able to reliably identify the source of issued records.
• The Working Group may choose to publish the proof of payment vocabulary as a distinct specification because it may not be required for some transactions and is therefore less critical to a minimum viable payment flow.
• For each vocabulary, the Working Group will create at least a JSON-LD serialization and may create additional serializations (e.g., XML).
• Easy format extensibility will help accommodate the data requirements of numerous and diverse payment schemes.

Web Payment Registration and Discovery 1.0

The Working Group will define best practices for the registration and discovery of payer payment instruments with their User Agents.

• User Payment Instrument Registration: Best practices that should be followed by the wallet for the payer to register and unregister payment instruments.
• User Payment Instrument Discovery: An algorithm that should be used against the payer's registered payment schemes and instruments and those in a payment request for a particular transaction for the purpose of determining which may be used.

Notes:

• The payee does not have direct access to the payer's schemes.
• While the payee will not have knowledge of the payer's available payment instruments(s) by default, the Working Group may discuss and propose solutions for sharing information about payment instruments with the payee with user consent.
• Registration will require identifiers that will vary depending on whether the wallet is hosted in the browser, in a native operating system, or in the cloud.

Web Transactions 1.0

The Working Group will define WebIDL APIs that enable the following:

• Web Payment Initiation: This API passes a payment request from the browser to the user's default wallet and returns the details of the payment initiation response from wallet. The wallet should compile a set of payment instruments to be presented to the payer for selection and gather the required data to pass back to the payee with user mediation where necessary.
• Web Payment Completion: This API passes a payment completion request from the browser to the user's default wallet and returns the details of the payment completion response from the wallet. If this was a payer initiated payment this is the trigger to execute the payment otherwise this is a message advising of the result of a payee initiated payment.

Notes:

• Question (from DSR): There will be software that provides the user interface for payment instrument selection. This should be able to take into account context (e.g., which payee, geolocation, user preferences, defaults, etc.). While the browser could do this, it could also be done by an independent software agent that is not tied to a particular set of payment instruments. This agent could also fulfill the role of providing access to preferences, receipt container, and more. Should this agent be visible through APIs? Does it have a name?

• Answer (from AHB): I propose that we be explicit and call this a wallet and that for this version of the charter we define what an interface to a wallet should look like (the Web Transactions 1.0 API).

Milestones

Specification	FPWD	CR	PR	REC
Web Payment Vocabularies 1.0	1 March 2016	@@	@@	June 2017
Web Payment Registration and Discovery 1.0	1 April 2016	@@	@@	November 2017
Web Transactions 1.0	1 April 2016	@@	@@	November 2017

Dependencies and Liaisons

W3C Groups

• Web Application Security WG
• (New) Web Authentication WG
• (New) Hardware-based Security
• (New) Credentials WG
• Web Payments Interest Group
  • For use cases and requirements
• Web Crypto WG
  • For encryption and signatures
• Privacy Interest Group
  • For reviews
• Security Interest Group
  • For reviews

Other Organizations

• GSMA
• IETF
• ISO TC 68
• SWIFT
• X9