Copyright © 2014 the Contributors to the Web Payments Use Cases Specification, published by the Web Payments Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.
The purpose of the Web Payments Community Group at the World Wide Web Consortium (W3C) is to create systems that enable people and businesses on the Web to send each other money as easily as they exchange instant messages and email today. The systems strive to be easy to use, currency agnostic, secure, decentralized and implementable by anyone in a patent and royalty-free manner. The group is focusing on transforming the way we reward each other on the Web as well as how we organize financial resources to enhance our personal lives and pursue endeavors that improve upon the human condition. The following use cases outline the basic functionality that the group is attempting to achieve.
This specification was published by the 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.
The Web continues to transform the way humankind communicates and builds our world. At the heart of most of these endeavors is the exchange of value. Gifts, attention, and payments each play a role in the ecosystem that we call the economy. Until now, there has been no open and universal way of sending and receiving payments on the Web through your browser. This is why people are still compelled to reach for their credit card or log into a payment site when purchasing something over the Web.
There are a number non-interoperable payment solutions today. This document outlines use cases that are supported by existing payment solutions today, and also outlines innovative use cases that could be supported in the future by a universal payment mechanism to enable next generation mobile payments, alternative currencies, crowd-sourced investing, next-generation banking, and electronic commerce.
This specification outlines use cases that are enabled by universal payment for the Web. The goal of addressing the use cases as a whole is to create a safe, decentralized system and a set of open, patent and royalty-free specifications that allow people on the Web to send each other money as easily as they exchange instant messages and e-mail today. Addressing these scenarios will transform the way we reward each other on the Web as well as how we organize financial resources to enhance our personal lives and pursue endeavors that improve upon the human condition.
There is certain terminology used throughout this document that has a very specific meaning. In order to state explicitly what that meaning is, the following definitions are provided:
Each interaction in a Web Payments scenario involves a number of entities. In order to make it clear who the actors are, the following roles are defined:
In order to interact, an entity may require one or more pieces of information from another entity. Each of these pieces of information, which may be digitally signed by a 3rd party, are called a credential. The following credentials are commonly used throughout this document:
When exploring systems design, there are concepts that clearly fit into use cases and concepts apply to all use cases. We are calling the latter class of concepts design criteria, which are goals that should be kept in mind while designing the overall web payments system.
Consider using Web Intents or Protocol Handlers to provide an abstraction layer that could be used to solve both payment initiation and other problems on the Web.
Require data portability for financial data and credentials that is required for core transaction functionality.
Ensure the Web payments solution can provide an abstraction layer that integrates with existing payment methods (eg: VISA, Mastercard, ACH, PayPal, debit card, Premium SMS, etc.)
Ensure the technology can be extended or does not prohibit the implementation of simple digital contracts and smart contracts.
Don't prevent a physical version of a digital receipt that can be verified, perhaps by printing out a QR Code on a slip of paper with some additional information.
The following use cases outline scenarios that are targeted to be supported in the set of Web Payments 1.0 specifications.
A buyer selects an item to purchase on merchant's site, merchant generates a purchase request that will be processed by the buyer's payment processor.
When a payee intends to make a payment, they are given a choice to pick among the intersection of the payment processors they're registered with and the payment processors that are advertised by the merchant/payee.
A merchant advertises different details, such as price, for an offer of sale based on potential payment processor choice.
A buyer can associate a membership card, coupon, or similar token with a transaction to receive a discount or other benefits.
Leveraging variable degrees of pseudo-anonymity per requirements of the payment transaction.
A buyer discovers an offer for sale by a merchant under terms that the merchant is comfortable with. The offer includes a list of payment processors that the merchant is capable of receiving payment through. The buyer's software contacts a subset of those payment processors that they are capable of sending payment through to get finalized transaction details (such as price or speed) before executing the most desirable transaction.
Payee and payers negotiate secure price in an open market. They are free to choose all three essential attributes of the numeric quantity expressing a price (e.g. 10.99), namely: a unit-of-account (e.g. $ £ € ¥ etc.); a medium-of-exchange (e.g. debit card, credit card, web payment etc.); and, a value-in-exchange benchmark (e.g. WM Reuters Spot Exchange; Purchasing Power Parity; Commodity Index; etc.)
A buyer uses a native non-browser application on their mobile phone or tablet, or a web browser to make a purchase at an app store.
A buyer makes a purchase from within an application for premium content, virtual goods, or subscriptions.
Temporary payment tokens for merchants. If token is stolen, thief does not get access to financial account. Tokenization mechanism that protects the buyer and merchant from theft of credentials.
The buyer goes to a merchant website and clicks a buy button to complete a purchase without having to go through any registration process. During the purchase the buyer chooses which information to share with the merchant which the merchant then uses to uniquely identify the buyer if they perform any repeat purchases.
The buyer goes to a merchant website and clicks buy to initiate a purchase. The buyer is redirected to their payment processor's website which presents them with a payment UI. The buyer completes the purchase (optionally without providing any information other than their consent). The buyer is sent back to the merchant's website with a digital receipt confirming the purchase.
A buyer visits a merchant's website and initiates a payment. Their payment processor presents them with an option to subscribe to a merchant's product or service, which will result in periodic payments at a known value to the merchant.
A buyer visits a merchant's website and initiates a payment. Their payment processor presents them with an option to assign a pay-as-you-go token with a specific spending limit (and/or other limitations) for future purchases with the merchant. An option is also presented to require the display of a receipt when a purchase occurs (and/or other interactions), or to perform the purchase in the background with no interactive purchase process required.
An entity (payer, payee, merchant, buyer) stores wallet, credentials, and digital receipts with a particular identity/wallet/data storage provider. The entity decides to switch to a different identity/wallet/data storage provider and all wallet, receipt, and credential data comes with them.
A payment processor tracks mandatory financial regulatory events and submits machine-readable information to a regulator-provided URL to automatically meet regulatory compliance.
A merchant cryptographically-signs a standardized offer for a good or service. A buyer purchases the good or service from the merchant resulting in a standardized, cryptographically signed, machine-readable, digital receipt that is issued to the buyer. Entities involved in the transaction (merchant, buyer, payee) may then use the receipt as a proof-of-purchase for the good or service.
The editor is thankful to the following contributions from the Web Payments Workshop and the Web Payments Community Group, specifically (in alphabetical order): TBD