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

Introduction

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.

Glossary

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:

entity
a thing with distinct and independent existence such as a person, organization, or instance of a software program.
credential
a qualification, achievement, quality, or piece of information about an entity’s background such as a name, government ID, payment processor, home address, or university degree.
transaction
a transfer of value from one entity to another.
digital receipt
a proof of purchase that verifies that a particular entity was involved in a transaction.

Roles

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:

payer
the entity sending value in a transaction.
payee
the entity receiving value in a transaction.
buyer
an entity purchasing a product or service.
merchant
an entity that is offering a product or service for sale.
payment processor
an entity that is responsible for transferring value between entities and generating verifiable digital receipts.

Credentials

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:

identity credential
An identity credential contains a pseudo-anonymous URL that can be used to uniquely identify an entity. The URI typically doesn't contain any personally identifiable information.
email credential
An email credential contains a verified email address and proves that the entity associated with the credential has verified their email address with a 3rd party.
payment processor credential
A payment processor credential contains a verified payment processor URL that was assigned to the entity associated with the credential by their payment processor.
shipping address credential
A shipping address credential contains a verified address where shipping deliveries may be made that is also associated with the entity associated with the credential. Typically, organizations that are capable of associating a shipping address with an entity, such as the United States Postal Service, provide these credentials.

Design Criteria

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.

Web Intents / Protocol Handlers

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.

Examples

  • Trisha signs up with a new payment processor service, and during the registration, the service asks if it may be used to process the "buy:" intent/protocol.
  • Ravi finishes placing all the items to buy into his shopping cart, when he clicks the "Pay" button, the "buy:" intent/protocol handler is initiated, resulting in a UI flow that requests that he picks which of his payment processors he'd like to use for the purchase.

Details

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.

Data Portability

Require data portability for financial data and credentials that is required for core transaction functionality.

Examples

  • Ginger would like to move her banking provider from MehBank to GoodBank. She goes to GoodBank and initiates a "Transfer My Account" process. GoodBank connects to MehBank, with the authorization of Ginger, and pulls her entire account history, digital receipt data, and balance to MehBank.

Details

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.

Legacy Support

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

Examples

  • Harold buys a movie ticket to his local movie theatre via the Web. He is given a choice of paying with a credit card, PayPal, or Bitcoin. The digital receipt delivered to the merchant will be in one machine-readable format to ensure that the merchant can process each type of digital receipt in a generic fashion.
  • Reece gets a weekly share of vegetables through a community-supported agriculture initiative. He may choose to pay using fiat money, or via work credits based on the number of hours he's worked on the farm. He pays in work credits, which is a hyper-local currency issued by the community-supported agriculture program. The digital receipt format only differs in the type of currency that was used to complete the sale.

Details

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.

Authorization Configurability

Allow payment processors to define the required level of authorization for particular transactions based on their preferences and local regulations. For example: No auth for small amounts, PIN auth for medium amounts, Secure Element for large amounts.

Examples

  • Sven buys a single play for an online video game. His payment processor allows the purchase with no authorization due to the low value of the transaction.
  • Joyce initiates a monthly mortgage payment. She is asked to verify the purchase using a 2-factor authentication method that she had previously registered with her payment processor.
  • Nimo buys a new car online. He is asked to authorize the purchase by digitally signing a purchase contract and then using his two-factor authentication device to verify the transfer of funds.

Details

There is an important balance between convenience and security that is typically context-sensitive. It not only depends on the situation and the type of transaction, but the payment processor and the payee's preferences as well. It is important that the type of authentication used for transaction is left to the entity's involved in the transaction, and is not hard-coded into the payment protocol.

Smart Contracts

Ensure the technology can be extended or does not prohibit the implementation of simple digital contracts and smart contracts.

Examples

  • Quoma owns a small-scale bakery that sells bread to local stores. She creates a smart contract for pricing goods with her local stores ensuring that she can make a 20% profit over the input of goods into her bread. She ties the cost of wheat, energy, and water to the smart contract so that the price per loaf of bread tracks the market price for the inputs.
  • Harim buys a piece of land on a 15 year mortgage. The smart contract that he executes with the mortgage lender will execute a withdrawal from his account to the lender's account on a monthly basis.

Details

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.

Physical Receipts

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.

Examples

  • Bertrand purchases a bus ticket at a booth using his mobile phone. The digital receipt for the ticket is printed out on a piece of paper, which he then takes and presents to a gate with a barcode scanner that scans the ticket and gives him access to the public transportation building.

Details

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.

Use Cases

The following use cases outline scenarios that are targeted to be supported in the set of Web Payments 1.0 specifications.

Purchase Request

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.

Examples

  • Penny logs into a website, providing her payment processor credential in the process. Penny selects a model train set to buy in an online shop. The store generates a payment request and hands it off to the browser which then forwards the her preferred payment processor.

Details

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.

Roles

  • buyer
  • merchant
  • payment processor

Credentials

  • payment processor credential

Requirements

  • A mechanism that enables the buyer's payment processor to be discovered MUST be standardized.
  • A purchase request format MUST be standardized.

Payment Links

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.

Examples

  • Gus is a web developer and creates a donation link on his website. He inserts a
    <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.

Details

A new payment protocol would enable a new type of hyperlink on the Web that would be specialized for payments.

Roles

Credentials

Requirements

Choice of 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.

Examples

Details

Roles

Credentials

Requirements

Parametric Offers

A merchant advertises different details, such as price, for an offer of sale based on potential payment processor choice.

Examples

Details

Roles

Credentials

Requirements

Coupons and Loyalty Cards

A buyer can associate a membership card, coupon, or similar token with a transaction to receive a discount or other benefits.

Examples

Details

Roles

Credentials

Requirements

Pseudo-anonymity

Leveraging variable degrees of pseudo-anonymity per requirements of the payment transaction.

Examples

Details

Roles

Credentials

Requirements

Transaction Fee Optimization

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.

Examples

Details

Roles

Credentials

Requirements

Choosing the Attributes of Price

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

Examples

Details

Roles

Credentials

Requirements

App-Store Purchases

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.

Examples

Details

Roles

Credentials

Requirements

In-App Purchases

A buyer makes a purchase from within an application for premium content, virtual goods, or subscriptions.

Examples

Details

Roles

Credentials

Requirements

Payment Tokenization

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.

Examples

Details

Roles

Credentials

Requirements

Registration-less Purchases

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.

Examples

Details

Roles

Credentials

Requirements

Push-based Payments

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.

Examples

Details

Roles

Credentials

Requirements

Subscriptions

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.

Examples

Details

Roles

Credentials

Requirements

Non-interactive Purchases

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.

Examples

Details

Roles

Credentials

Requirements

Digital Wallet Portability

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.

Examples

Details

Roles

Credentials

Requirements

Real-time Regulatory Reporting

A payment processor tracks mandatory financial regulatory events and submits machine-readable information to a regulator-provided URL to automatically meet regulatory compliance.

Examples

Details

Roles

Credentials

Requirements

Digital Receipts

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.

Examples

Details

Roles

Credentials

Requirements

Acknowledgements

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.