Skip to Content

Web Payments Standards


This roadmap document outlines the proposed technology stack and development timeline for the set of technologies being worked on by the Web Payments Community Group.

Status of This Document

This specification was published by the W3C Web Payments Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

This is an experimental document that is being actively worked on by the W3C Web Payments Community Group. All feedback on this document should be sent to (archive).

If you wish to make comments regarding this document, please send them to (subscribearchives).

table of contents

1. Introduction

This document outlines the technology stack and development timeline for the set of technologies being worked on by the Web Payments Community Group. It is intended for those people that want to understand all of the technical pieces being proposed, how they fit together, and the development timeline for each technology.ISSUE 1

Readers should understand that this roadmap document is a work in progress and while many of the technologies discussed in this document have been implemented and are in production, others may be changed or modified heavily if driven through a standardization track at W3C. This document is a proposed roadmap, not the final roadmap for version 1.0.

A common question that’s raised when someone is introduced to the Web Payments work is whether or not a particular payment technology, like blockchain-based ledgers, are supported or whether their existence invalidates the specification stack that is being proposed. In general, the realization that the Web Payments Community Group has come to over the many years that it has been operating is that there will never be only one way of doing payments. Therefore, the specifications that are being proposed do not assume a single dominating payment instrument or technology. Instead, the specifications focus on the more general mechanisms that are required to express a transaction and not the specifics that move value from one account to another. For example, the technology proposed by this group primarily focuses on the following:

  • The expression of digitally verifiable claims via credentials. For example, proof-of-age, government-issued ID cards, corporate ID cards, proof-of-skillset, and other things necessary to fulfill Know Your Customer (KYC) and Anti-Money Laundering (AML) requirements.
  • Machine-readable expression of product and service offers for sale via the Web. For example, BigRecordsInc is selling SuperstarBand’s new song One Hit Wonder for $5 USD.
  • Payment initiation on the Web which would allow browsers and other Web clients to have one standardized way of initiating a payment that is payment instrument and payment processor agnostic.
  • Digital receipts that would be able to be used as a proof-of-purchase and would support multiple types of payment instruments and networks.

The Web Payments Community Group realizes the importance of supporting the current payment instruments that exist today (e.g. credit cards, ACH, electronic checks, etc.) as well as the established value benchmarks (e.g. WM Reuters Spot Rate) while also ensuring that the proposed technologies take other more future-facing solutions into account (e.g. blockchains, sidechains, smart contracts, DAOs, etc.) as well as new methods for algorithmic pricing and benchmarking. Rather than hard-coding each of these technologies into the Web Payments specifications, we take a more general approach. Each one of these current and future systems and technologies is supported in a generic way in order to ensure that the specifications remain as agnostic as possible to the underlying operation of each payment instrument, value benchmark, and payment clearing technology.

web payments standard

2. Technology Stack

The Web Payments technology stack is designed on generally accepted design principles outlined for the Architecture of the World Wide Web[WEBARCH]. It also heavily re-uses W3C and IETF technology, such as JSON-LD [JSON-LD-SYNTAX] and HTTP [RFC7230]. A high-level diagram of the technology stack is shown below for reference:


A description of the technologies shown in the diagram above is provided for those that may be unfamiliar with the technologies:Javascript Object Notation [RFC4627]JavaScript Object Notation (JSON) is a text format for the serialization of structured data. JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays). It is a very popular format among Web developers.HyperText Transport Protocol [RFC7230]The Hypertext Transfer Protocol (HTTP) is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do not need to be aware of each client’s purpose: an HTTP request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used effectively in many different contexts and for which implementations can evolve independently over time.JSON for Linking Data [JSON-LD-SYNTAX]JSON-LD is a lightweight syntax to serialize Linked Data in JSON [RFC4627]. Its design allows existing JSON to be interpreted as Linked Data with minimal changes. JSON-LD is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Web services, and to store Linked Data in JSON-based storage engines.Signing HTTP Messages [HTTP-SIGNATURES]When communicating over the Internet using the HTTP protocol, it can be desirable for a server or client to authenticate the sender of a particular message. It can also be desirable to ensure that the message was not tampered with during transit. The “Signing HTTP Messages” specification describes a way for servers and clients to simultaneously add authentication and message integrity to HTTP messages by using a digital signature.RDF Dataset Normalization [RDF-NORMALIZATION]RDF (which JSON-LD uses) utilizes a graph-based data model for making claims about the world and provides the foundation for reasoning upon that graph of information. At times, it becomes necessary to compare the differences between graphs, digitally sign graphs, or generate short identifiers for graphs via hashing algorithms. RDF Dataset Normalization outlines an algorithm for normalizing RDF graphs such that these operations can be performed on the normalized graphs.Secure Messaging [SECURE-MESSAGING]The Secure Messaging specification describes a simple, decentralized security infrastructure for the Web based on public key cryptography. This system enables Web applications to establish identities for agents on the Web, associate security credentials with those identities, and then use those security credentials to send and receive messages that are both encrypted and verifiable via digital signatures.Web Commerce [WEB-COMMERCE]In order to support standardized commerce over the Web, it is vital that product offers and the result of purchases can be expressed in a simple manner. This specification enables the decentralized offer of products and services for sale and the transaction process resulting in a digitally verifiable receipt between the buyer and the vendor.Identity Credentials [IDENTITY-CREDENTIALS]An identity is a description of a particular entity such as a person, software agent, or organization. A credential is a qualification, achievement, quality, or information about an identity’s background such as a name, government ID, home address, or university degree. The Identity Credentials specification describes mechanisms for reading credentials from and writing credentials to an identity while ensuring that the information is only accessible to authorized applications.Web Commerce API [WEB-COMMERCE-API]This specification outlines a browser polyfill that makes financial transactions easier to initiate and verify while also making them more secure. The solution is designed to work with both proprietary (PayPal, Google Wallet) and non-proprietary (PaySwarm, Bitcoin, Ripple) payment solutions.

3. Timeline

The technologies proposed by the group are layered in such a way to allow the base technologies to be re-used by other Web-based standards. Thus, there is a natural order of progression in developing these technologies, from low-level to high-level:

4. Active Collaborators

A. References

A.1 Informative references

[HTTP-SIGNATURES]Mark Cavage; Manu Sporny. IETF. HTTP Signatures. 4 May 2013. W3C Working Draft. URL:[IDENTITY-CREDENTIALS]Manu Sporny; Dave Longley. W3C Credentials Community Group. Identity Credentials. CG-DRAFT. URL:[JSON-LD-SYNTAX]Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. JSON-LD 1.0. 3 November 2020. W3C Recommendation. URL:[RDF-NORMALIZATION]Dave Longley; Manu Sporny. W3C JSON for Linking Data Community Group. RDF Dataset Normalization. CG-DRAFT. URL:[RFC4627]D. Crockford. IETF. The application/json Media Type for JavaScript Object Notation (JSON). July 2006. Informational. URL:[RFC7230]R. Fielding, Ed.; J. Reschke, Ed.. IETF. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Standard. URL:[SECURE-MESSAGING]Dave Longley; Manu Sporny; David I. Lehn. W3C Web Payments Community Group. Secure Messaging. CG-DRAFT. URL:[WEB-COMMERCE]Dave Longley; Manu Sporny; David I. Lehn. W3C Web Payments Community Group. Web Commerce. CG-DRAFT. URL:[WEB-COMMERCE-API]Manu Sporny; Dave Longley; David I. Lehn. W3C Web Payments Community Group. Web Commerce API. CG-DRAFT. URL:[WEBARCH]Ian Jacobs; Norman Walsh. W3C. Architecture of the World Wide Web, Volume One. 15 December 2004. W3C Recommendation. URL: