Abstract

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.

Status of This Document

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.

Table of Contents

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

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

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

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

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

5.1 Web Intents / Protocol Handlers

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.

Details

5.2 Data Portability

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

Details

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

Details

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

Details

5.5 Smart Contracts

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

Details

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

Details

6. Use Cases

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

6.1 Purchase Request

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.

Details

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

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

Details

Roles
Credentials
Requirements

6.4 Parametric Offers

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

Details

Roles
Credentials
Requirements

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

Details

Roles
Credentials
Requirements

6.6 Pseudo-anonymity

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

Details

Roles
Credentials
Requirements

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

Details

Roles
Credentials
Requirements

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

Details

Roles
Credentials
Requirements

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

Details

Roles
Credentials
Requirements

6.10 In-App Purchases

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

Details

Roles
Credentials
Requirements

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

Details

Roles
Credentials
Requirements

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

Details

Roles
Credentials
Requirements

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

Details

Roles
Credentials
Requirements

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

Details

Roles
Credentials
Requirements

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

Details

Roles
Credentials
Requirements

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

Details

Roles
Credentials
Requirements

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

Details

Roles
Credentials
Requirements

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

Details

Roles
Credentials
Requirements

7. Acknowledgements

The editor is thankful to the following contributions from the Web Payments Workshop and the Web Payments Community Group, specifically (in alphabetical order): TBD