Payments and the ability to exchange value efficiently and securely over the web are critical to global commerce. Open standards for payments and value exchange help ensure open access and interoperability to financial systems for all the people that use the Web. This document describes aset of capabilities that, if standardized, will improve payments on the Web.

This document is in early draft state and is expected to rapidly evolve based on broad feedback and input from the Web Payments Interest Group.

Introduction

This document needs an introduction! - SPM

Relationship to Other Documents

In addition to this document, the Web Payments Interest Group is developing:

Overview of Capabilities

Capabilities are functionalities necessary to implement payments on the Web. We include capabilities specific to payments but also capabilities that support payments (such as security) and capabilities more broadly related to commerce, as it is important to understand the full context in which payments occur.

We organize capabilities into five groups.

  1. Security Core - These capabilities provide the security foundation for payments.
    Capabilities: Key Creation and Management, Cryptographic Signatures, Encryption
    Right now this group has only security capabilities in it. We may wish to have a more general purpose Core set. If so, what would this core set include?
  2. Trust and Identity - Includes features related to establishing trust among parties, and credentialing or authorization of parties involved in a transaction.
    Capabilities: Identity, Credentials, Rights, Authentication, Authorization, Privacy, Discovery, Registration, Enrollment, and Legal/Regulatory concerns.
  3. Accounts and Settlement - Includes capabilities related to managing stores of value (such as Deposit Accounts) and recorded accounts of ownership (such as Ledger entries, Deeds, etc.) used as part of the settlement of payments or commercial exchanges. Settlement via the Web involves access to the accounts of the participants and ledgers of the account providers and capabilities to manage accounts and capture and monitor transactions in a ledger against those accounts.
    Capabilities: Accounts, Ledgers, and Legal/Regulatory concerns related to accounting and recorded ownership.
  4. Payments and Clearing - These are the capabilities that help parties in a transaction establish the mechanics of how the payment will be executed and the directly or indirectly make this happen. This involves the ability to discover and negotiate the mechanism that will be used to execute the payment and agree on the terms including facts such as the costs of making the payment, time between clearing of the payment and settlement into the payee’s account, regulatory requirements and required authorisations.
    Capabilities: Funding, Payment, Messaging, Clearing, Markets, Foreign/Currency Exchange, and Legal/regulatory concerns specific to Payments and Exchange of Value.
  5. Commerce - Includes capabilities related to commercial and economic interactions.
    Capabilities: Offers, Invoicing, Receipts, Loyalty, Rewards, Contracts, Lending, Insurance, Taxation, Legal/Regulatory concerns related to aspects of commercial and economic interactions.

The Interest Group anticipates that these groups will make it easier to define modules that may be reused at a variety of times in a payment transaction, to prioritize capabilities and craft charters for groups to standardize them, and to communicate the group’s plans with other standards bodies and organizations.

Some of these capabilities are expected be useful outside of payment scenarios.

Digital Wallets and Payment Agents

Although the capabilities described in this document may be used and composed in a variety of ways to fulfill payments use cases, the Interest Group anticipates that in many cases, they will be packaged in “payment agents” (or “digital wallets”) that act as a bridge between the merchant, the user, and the user’s account providers.

Capabilities in Context

To simplify and harmonize the descriptions of capabilities necessary for payments and value exchange on the Web, it is helpful to understand the parties involved and the direction that information flows among them at various phases of a payment. We use the following diagram to help illustrate roles and information flow:

InteractionsWheel.png

Figure: Payment Interaction Wheel

For example, the following diagrams illustrate three interactions in a comment payment scenario.

Request for Payment.png

Interaction 1:

Payee communicates request for payment to payer and shares payment instructions

Payer-PayeeService Provider.png

Interaction 2:

Payer uses information received from Payee and creates a new payment request from Payment Services Provider with stored value.

PSPtoPSP.png

Interaction 3:

Payer’s Payment Services Provider sends details to complete payment to Payee's Payment Services Provider

The roles illustrated here may be carried out by many different entities. For example, "account provider" may be carried out by financial institutions, mobile operators, tech companies, or cryptocurrency systems; “payee” may be an individual, a business, an NGO, or any entity that can accept a payment.

A payment may involve just two parties (e.g., peer-to-peer) or may be carried out by several collaborating parties. For instance, a payee may use a payment service provider which in turn uses a card network. The actions of these intermediaries may vary, from simply forwarding messages to fulfilling regulatory obligations. Additionally, these interactions may happen in different sequences and direction depending on the payment context.

Capabilities in Detail

Core and Security

  1. Key Management
    1. All participants require an interchangeable mechanism for creation, management, storage, and exchange of cryptographic keys
    2. Key management capabilities are required to:
      1. Securely communicate unique identifiers of payment process participants
      2. Digitally sign and authenticate information exchanged as part of the payments process (e.g., payments, receipts, invoices, etc.)
      3. Provide reference key for independent elements of the payments process to compose/link transactions and related data across asynchronous segments of the payment process
  2. Cryptographic Signatures
    1. Information transferred should be cryptographically signed to ensure
      1. Authenticity of the participants and ownership of value/asset being transferred or exchanged
      2. Nonrepudiationof participants intent related to information / communication being exchanged

Key Concepts:

(describe any key concepts/relationship to other capabilities here)

Suggested Deliverables:
  • Data model with a concrete syntax for expressing data in the architecture
  • Web-based key public key infrastructure data formats and protocols
  • New normalization mechanisms for data model serialization (if necessary, for digital signatures)
  • Digital signature mechanism for data model

Related Specifications:

  • Data models: Graph (RDF), Document/Tree (JSON, XML)
  • Syntaxes: XML, JSON, JSON-LD
  • Normalization: XML Canonicalization, RDF Dataset Normalization
  • Signatures: Linked Data Signatures, Javascript Object Signing and Encryption, XML Digital Signature

Responsible Working Group(s) or Standards Bodies:

  • Linked Data Signatures Working Group (W3C)
  • JOSE (IETF)

Identity and Credentials

  1. Identity
    1. Entities in the System are able to access Identity information of other parties it is interacting with if specifically required by law, or if consented to by owner of the information
    2. Identity and credentials of an entity are able to be linked/associated with Accounts and payments to satisfy requirements for Account Providers and Payments Service Providers to comply with KYC/AML requirements.
  2. Credentials
    1. Entities in the system are able to be associated with 1 or more credentials. A credential is a qualification, achievement, quality, or piece of information about an entity’s background such as a name, home address, government ID, professional license, or university degree, typically used to indicate suitability. Thisallows for the exchange of suitable qualities of the entity (ex. over age 21) without divulging sensitive attributes/details about the entity (ex. date of birth)
    2. Payer is able to exchange standard format credentials with Payee to validate attributes necessary to complete the payment
  3. Rights
  4. Authentication
    1. Participants are able to authenticate the validity of identifiers presented by entities that they are interacting with
  5. Authorization
  6. Privacy
    1. All capabilities in this document should be standardized in a way that minimizes the inclusion/exchange of personal or other sensitive metadata that are part of the payments process unless specifically required by law, or consented to by the owner of the information.
  7. Discovery
    1. Payer is able to securely locate public identifier of Payee to be used as part of payment process
    2. Payee is able to obtain public identifier of Payer participating in payment process
    3. Payer identifier is persistent across devices
  8. Registration
    1. Payer and Payee able to register with Payment Services Provider to obtain credentials used for payments process
  9. Enrollment
    1. Payment services provider is able to perform the necessary steps during payer/payee enrollment to collect required identity and credential information about the payer/payee and associate it with an Account.
  10. Legal/Regulatory concerns related to Trust and Identity

Key Concepts:

TO DISCUSS: Trust Agent???

Suggested Deliverables:

  • Data format and vocabularies for expressing cryptographically verifiable credentials
  • Protocol to issue credentials to a recipient
  • Protocol to store credentials at an arbitrary location as decided by a recipient
  • Protocol to request and transmit credentials, given a recipient’s authorization, to a credential consumer
  • Protocol to strongly bind an identifier to a real world identity and a cryptographic token (ex: two-factor hardware device)
  • Protocol to request and deliver untraceable, short-lived, privacy enhancing credentials.
  • Protocol to discover entity’s credential service

Related Specifications:

  • Identity Credentials (Credentials WG)
  • Credentials Vocabulary (Credentials WG)

Responsible Working Group(s) or Standards Bodies:

  • Credentials Working Group (W3C)
  • Authentication Working Groups (W3C)

Accounts and Settlement

Accounts

  1. Manage Accounts
    1. Payers and Payees (account owners) require the capability to create accounts at an account provider.
    2. Payers and Payees require the capability to authorise access to their accounts by third parties such as Payment Services Providers.
    3. Payers, Payees and other authorised entities require the capability of checking the current balance on an account.
  2. Account Registration/Enrollmentat Payments Services Providers
    1. Payers and Payees are able to register accounts that will be used as part of the payment process with Payment Services Providers of their choice
    2. Payers and Payees are able to delegate access to specific account functions to Payment Services Providers of their choice
  3. Receive Funds
    1. Payees are able to receive funds into theiraccounts
  4. Send funds
    1. Payers are able to transfer funds from their accounts

Key Concepts:

(describe any key concepts/relationship to other capabilities here)

Suggested Deliverables:

(include suggested/needed deliverables here)

Responsible Working Group(s) or Standards Bodies:

Related Specifications:

(Insert relevant related existing or in progress standards for capability segment)

Ledgers

  1. Discovery of Ledger services
    1. Participants require the capability to locate the endpoints at which ledger services are offered by an account provider
    2. Participants require the capability to discover which services are available against a ledger at an account provider
  2. Capture transactions in ledger
    1. Participants in the settlement process require the capability to capture a transaction in a ledger transferring value from one account to another on the same ledger.
  3. Monitor a ledger
    1. Participants in the settlement process require the ability to monitor a ledger for new transactions that impact a specific account.
  4. Reserve funds in an account
    1. To execute settlement across ledgers a counterparty may require the ability to request that an account provider temporarily reserve funds in an account while settlement is finalised on the other ledger(s).

Key Concepts:

TODO

Suggested Deliverables:

  • Standardised data model for accounts and ledgers
  • Standardised interface for account management
  • Standardised interface for ledger services
  • Protocol for discovering ledger services
  • Protocol for executing settlement between participants on the open Web

Related Specifications:

  • ISO20022 / X9 specs
  • Web Commerce Formats and Protocols (Web Payments WG)
  • Web Payments Vocabulary (Web Payments WG)

Responsible Working Group(s) or Standards Bodies:

  • Web Settlement Working Group (W3C)

Payments and Exchange

  1. Payment Instrument Discovery and Selection
    1. Payer and payee are able to discover payment instruments/schemes which they have in common and may be used in the payment process
    2. Payer is able to establish the different costs of making the payment using the various combinations of payer and payee instruments and schemes (payment methods)
    3. Payer is able to select payment instrument for use in the payment process
    4. Payee is able to communicate requirements(or preference) to payer as to whether a specific instrument is accepted and the payment terms for using that instrument
  2. Payment Initiation
    1. Payer is able to initiate a payment using selected payment instrument
    2. Payer is able to identify Payee via:
      1. Information received via Invoice
      2. Individual contact information
      3. Information from past payees
    3. Payee is able to initiate a request for payment to payee’s designated account provider
    4. Account provider is able to initiate a payment on behalf of the Payee based on Payee’s requested schedule and frequency (recurring payment)
  3. Payment Authorization
    1. Payment service provider or payee is able to get authorization from payer to execute payment either in real-time or using a preloaded authorization mechanism
    2. Payment service provider is able to demonstrate to payer account provider that payment is authorised
  4. Payment Execution
    1. Payment orchestrator is able to evaluate that all requirements have been met to execute the payment including authorization(s) and compliance checks as required.
    2. Payment orchestrator is able to instruct all participants to execute the payment and perform any roll-back steps that may be required in case of a failure by any participant to complete the payment.
  5. Payment Acknowledgement
    1. Payee is able to receive confirmation that payment has been successfully completed
    2. Payer is able to receive verification that payment has been successfully received
    3. Account provider is able to receive confirmation that payment is complete
  6. Regulatory/Legal Compliance
    1. Regulator is able to access/view required payment, payer, and payee details for payments that take place within their jurisdiction
    2. Regulator is able to intervene in payments meeting or exceeding certain thresholds or criteria in order to comply with jurisdictional laws and requirements
  7. Payment Settlement and Clearing
    1. Payment service provider is able to provide payer with quotesto settle payee via all payee supported payment schemes

Key Concepts:

TODO: Payment Agent

Suggested Deliverables:

  • Protocol for discovering all payment instruments available to a payer.
  • User Agent API and REST API for initiating a payment and protocol for routing an invoice to a payment service
  • Protocol for authorizing payment via regulatory API
  • User Agent API and REST API for completing a payment and protocol for routing payment acknowledgement to payer

Related Specifications:

  • ISO20022 / X9 specs
  • Web Commerce Formats and Protocols (Web Payments WG)
  • Web Commerce User Agent API (Web Payments WG)
  • Web Payments Vocabulary (Web Payments WG)

Responsible Working Group(s) or Standards Bodies:

  • Web Payments Working Group (W3C)

Commerce

Offers

  1. Generate Offer
    1. Payee is able to generate a standard format offer which provides information on specific products or services being offered, and additional information on payment instruments accepted, or terms of the offer.
    2. Payer is able to generate a standard format offer which can be accepted or declined by the payee.
    3. Payee is able to create scheduled/recurring offers
  2. Receive Offer
    1. Payer is able to receive offer in machine readable format and use it to initiate payment request
    2. Payeeis able to receive offer in machine readable format and use it to create invoice

Discounts

  1. Payee is able toable tocommunicate discounts which may be applied to Offers
  2. Payee is able to receive and apply discount to offer
  3. Payee is able to apply standard loyalty identifiers to offers

Coupons

  1. Payer is able to apply coupons to offers
  2. Payee is able to issue general use coupons
  3. Payee is able to issue coupons specific to payer identifier

Key Concepts:

Suggested Deliverables:

  • Data format and vocabularies for expressing offers and coupons
  • User Agent API for using an offer to initiate a payment

Related Specifications:

  • Web Commerce Formats and Protocols (Web Payments WG)
  • Web Commerce User Agent API (Web Payments WG)
  • Web Payments Vocabulary (Web Payments WG)

Responsible Working Group(s) or Standards Bodies:

  • Web Payments Working Group (W3C)

Invoices

  1. Invoice creation
    1. Payee is able to generate a standard formatted invoice and communicate to Payer as part of the negotiation of payment terms
  2. Invoice receipt
    1. Payer is able to receive standard formatted invoice
  3. Invoice data
    1. Invoice provides payer with Payment instructions for making payment to Payee
    2. Invoice identifier is returned to Payee via payment process to verify payment is complete

Key Concepts:

Suggested Deliverables:

  • Data format and vocabulary for expressing an invoice
  • User Agent API for initiating a payment and protocol for routing an invoice to a payment service

Related Specifications:

  • Web Commerce Formats and Protocols (Web Payments WG)
  • Web Commerce User Agent API (Web Payments WG)
  • Web Payments Vocabulary (Web Payments WG)

Responsible Working Group(s) or Standards Bodies:

  • Web Payments Working Group (W3C)

Receipts

  1. Create Receipt
    1. Payee is able to create receipt and communicate receipt to Payer following completion of payment
  2. Receive Receipt
    1. Payer is able to receive receipt and persist for future use (ex. returns, reimbursement, etc)

Key Concepts:

Suggested Deliverables:

  • Data format and vocabulary for expressing a receipt
  • Protocol for routing an receipt to a payer’s receipt storage service

Related Specifications:

  • Web Commerce Formats and Protocols (Web Payments WG)
  • Web Payments Vocabulary (Web Payments WG)

Responsible Working Group(s) or Standards Bodies:

  • Web Payments Working Group (W3C)

Loyalty

  1. Payer is able to register with Payee’s loyalty program by requesting loyalty identifier from Payee.
  2. Payee can “opt-in” to loyalty program by providing program specific public identifier

Key Concepts:

Suggested Deliverables:

  • Same as “Trust” deliverables

Related Specifications:

  • Identity Credentials (Credentials WG)

  • Credentials Vocabulary (Credentials WG)
  • Web Commerce Vocabulary (Credentials WG)

Responsible Working Group(s) or Standards Bodies:

  • Credentials Working Group (W3C)

Guiding principles and key considerations

Due to the breadth of the capabilities that will require standardization, it is important to outline certain guiding principles which are expected to be incorporated across each of the defined capabilities in this document as they are undertaken by standards teams. The principles include:

Extensibility

Composability

Identifiers

Security

Identity, Privacy, and Consumer Protection

Legal and Regulatory

Accessibility

Discovery and instrument selection

Glossary

@@The Web Payments Glossary@@ defines additional terms and relates this group’s definitions to those from related standards.