This document is the architecture vision statement of the W3C Web Payments Interest Group. It describes the principles upon which a Web Payments architecture should be built.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports indexat http://www.w3.org/TR/.

This document represents the consensus of the Web Payments Interest Group as of the publication date of this document. See the 28 May 2015 Call for Consensus.

Previous versions of this document were maintained on the group's wiki.

This document was published by the Web Payments Interest Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-webpayments-comments@w3.org (subscribe, archives). All comments are welcome.

Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 August 2014 W3C Process Document.

Table of Contents

1.Web Principles

Any architecture grounded in the Web should respect well-known Web principles such as:

2.Desirable properties of a Web Payments Architecture

In addition to the principles above, the following are desirable properties specific to a Web payments architecture:

2.1Provides payees and payers unencumbered knowledge and choice in how to undertake payments

It is consistent with the purpose of the Web to enable payees to receive payments, and payers to pay, using their preferred payment instruments and payment schemes. The Web payments architecture must not restrict these choices but rather foster transparency of choices available.

2.2Improves the user experience

We want to improve the user experience in a variety of ways. These include reducing the need to provide data as part of a transaction (helpful on mobile in particular), simplifying payment user interfaces and interactions, standardizing the payment flow across all Web applications, and making it easier to make payments from a wide range of devices, such as computers, portable devices, televisions, eBooks, and automobiles.

Taken together, we expect these improvements will lower the rate of "cart abandonment" and increase the velocity of payments made over the Web.

2.3Supports a wide spectrum of security and privacy needs to meet industry expectations

Trust in Web payments is critical to their widespread adoption. Because of this the architecture must provide the ability for participants in the payment process to confidently, securely and accurately identify and connect to other participants that are party to the payment.

The architecture should not disclose private details of the participants identity or other sensitive information as part of the payment process unless required by operational, legal or jurisdictional rules, or when deliberately consented to (e.g. as part of a loyalty program) by the owner of the information.

The Web payments architecture should make this easy by standardizing the mechanisms available to issue, exchange and verify credentials as part of a payment transaction, as well as a secure mechanism for the exchange of identity information when it is explicitly required as part of a payment. To accomplish this, it is expected that the architecture will also need to support an evolving variety of authentication and identification techniques (e.g. multifactor, biometric, etc.) which can be used independent of or in concert with a participants identity data.

2.4Encapsulates existing payment schemes and enables new schemes

In order to achieve this, we anticipate that the architecture will be:

2.5Encourages efficient settlement

Different payment schemes move value at different speeds. The Web payments architecture should not impose additional delays, so that payment information circulates as efficiently as possible and the final settlement (exchange of value) is done as quickly as possible.

2.7Enables monetization on the spectrum of Web to native apps

Web developers will be able to integrate payments smoothly into a variety of user experiences on the Web, including in-app payments, downloads, and subscriptions. This is key to opening up new revenue generating opportunities on the Web that were not previously viable due to the costs incurred and poor user experiences required in processing payments.

2.8Bridges distributed value networks

The Web will ultimately serve as a bridge between open and closed value exchange networks, enabling interoperable value exchange. This will enable both payers and payees to seamlessly make payments using a variety of previously non-interoperable payment instruments.


The editors wish to thank the participants of the Web Payments Interest Group for discussions about and contributions to this document, as well as the Web Payments Community Group for earlier work that informed this document.