Copyright © 2014 the Contributors to the Web Payments Community Group Use Cases Specification, published by the Web Payments Community Group under the W3C Community Final Specification Agreement (FSA). 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 Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups.
This document was created in the Web Payments Community Group and, in November 2014, was handed off to the Web Payments Interest Group for further refinement, development, and integration into the official set of Web Payments IG use cases.
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 a Web Intents or Protocol Handler-like mechanism to provide an abstraction layer that could be used to solve both payment initiation and other problems on the Web.
Web Intents or Protocol Handlers could be used as a simple way of solving the payment selection NASCAR problem. Instead of showing a large array of payment providers that are supported by the merchant, a dialog can be shown instead that only shows the payment mechanisms that are supported by both the payer and the payee. A payment provider may register as one potential handler for a particular intent/protocol scheme, and when the scheme is invoked, the payer is asked which handler they'd like to use to handle the request.
Require data portability for financial data and credentials that is required for core transaction functionality.
It is often difficult to easily switch financial providers. This will become more difficult if the use of digital receipts becomes pervasive. If one needs a digital receipt to prove that a purchase has been made, then the curator of those digital receipts, like a bank, could use them as a customer lock-in mechanism. Therefore, it is important that any information that is expected to be used in transactions has a provable data portability story.
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.)
In order for the Web Payments initiative to be successful, it must not discriminate based upon payment instrument or currency. As many types of payment instrument as possible should be supported.
Ensure the technology can be extended or does not prohibit the implementation of simple digital contracts and smart contracts.
Smart contracts, which are typically referenced when discussing Distributed Autonomous Organizations, provide the capability of algorithmically defining the distribution of economic value. While it is too early to define a smart contract platform for the Web Payments work, the creation of such a platform or set of protocols and formats in the future should not be prevented.
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.
In designing the protocols and formats for the Web Payments work, it is important that offline-only is taken into account. One manifestation of this design requirement is the paper receipt or magnetic-stripe ticket.
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 payment request that will be processed by the buyer's payment processor.
A payment request contains all of the details necessary to perform a purchase. The payment request should be a self-contained document that can be used interchangeably with any payment processor that supports the payment instrument specified in the payment request.
A developer can create a link with a specific payment URI scheme or rel-type such that when a buyer clicks on it, the buyer's payment processor starts the payment process.
<a href="payto:bitcoin:3782436823487?message=Donation">Donate</a>link in the web page markup such that when someone clicks the "Donate" link, a payment will be initiated using the payer's payment processor.
A new payment protocol would enable a new type of hyperlink on the Web that would be specialized for payments.
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):
Mahmoud Abdelkader, Jonas Öberg, Ben Adida, Mike Amundsen, Erik Anderson, Gavin Andresen, Dennis A. Smith, Daniel Austin, Margaux Avedisian, Craig B. Agricola, Arthur Barstow, Rene Bartsch, Michiel B. de Jong, Tim Becker, Robin Berjon, Tim Berners-Lee, Norbert Bollow, Carsten Bormann, John Bottoms, Andrew Bovingdon, Stephane Boyera, Pelle Braendgaard, Erich Bremer, Arthur Britto, Martin Brock, Daniel Buchner, Marcos Caceres, Dan Callahan, Stephen Cannon, Melvin Carvalho, Joe Cascio Jr., Ryan Charleston, Daniel Chcouri, Jeffrey Chimene, 조경호, Jeffrey Cliff, Stephane Corlosquet, Ralph Cowling, Jon Cox, Cyrus Daboo, Nicolas Dagostino, Josef Davies-Coates, Renaud Delbru, Jose De Loera, Joel Dietz, Karl Dubost, Andrew Durham, Scott Elcomb, Charles Evans, Roman Evstifeev, David Ezell, Stephen Farrell, Pascal Finette, Daniel Friesen, Ryan Fugger, Shawn Gao, Bruce Garrison, Jason Grant, Urs Gubser, Harry Halpin, Timo Hanke, Daniel Harris, Mike Hearn, Brian Hegarty, Martin Hepp, Bjoern Hoehrmann, Tim Holborn, Timothy Holborn, Adrian Hope-Bailie, Jake Howerton, Deqing Huang, Renato Iannella, Kingsley Idehen, David I. Lehn, Ian Jacobs, Mark Janssen, Phil J. Laszkowicz, Mike Johnson, Michael J. Williams, Gregg Kellogg, Frode Kileng, Steve Klabnik, Greg Knaddison, Ya Knygar, Eric Korb, Kostas Koukopoulos, Andreas Kuckartz, Dave Lampton, Juan Lang, Stuart Langridge, Bruce Lawson, Guillaume Lebleu, Georg Leciejewski, Mark Leck, Mountie Lee, Randall Leeds, Adam Levine, Patrick Logan, Dave Longley, Alex MacCaw, Andrew Mackie, Jeremy Malcolm, Niels Möller, James Manger, Jose "Manny" De Loera, Eric Martindale, Sam Mbale, Charles McCathie Nevile, Kumar McMillan, Russell McOrmond, Coralie Mercier, Andrew Miller, Clark Minor, Matt Morgan, Glen Newton, Russel Nickson, David Nicol, Yoav Nir, Madhu Nott, Mark Nottingham, Yutaka Oiwa, Emeka Okoye, Linus Olsson, Andrei Oprea, Nate Otto, Elf Pavlik, Iris Peetz, Laurent Perez, Neil Peters, Joseph Potvin, Michael Powers, Dave Raggett, Julian Reschke, Bailey Reutzel, Pierre Rochard, Natasha Rooney, Jonathan Rosenne, Steven Rowat, Anders Rundgren, Sean Safahi, Andrei Sambra, Jeff Sayre, Doug Schepers, David Schwartz, Evan Schwartz, Igor Schwarzmann, Alex Sexton, Brent Shambaugh, Herbert Snorrason, Stan Stalnaker, Walter Stanish, Henry Story, John Sullivan, Amir Taaki, Keisha Taylor, Michael Thomas, Martin Thomson, Emanuil Tolev, Dziugas Tornau, Hannes Tschofenig, Ricardo Varela, Jonathan Waller, Dr. Warren L. Coats Jr., Michael Williams, Nico Williams, Robin Wilton, Pindar Wong, David Wood, Apostolis Xekoukoulotakis, Dan York, and Jorge Zaccaro.