The purpose of this document is to outline a coherent implementation and deployment strategy for the Web Payments standardization work at W3C.

This document is a work in progress and is being released early and often using an agile process; it is incomplete.

Introduction

The purpose of this document is to outline a coherent implementation and deployment strategy for the Web Payments standardization work at W3C. It consists of the following major sections:

Relationship to Other Documents

This document is one part of a greater body of work around Web Payments that the Web Payments Interest Group at W3C is producing. These other documents include:

Terminology

Coordination

In order for the Web Payments Activity to succeed, multiple groups will need to coordinate work in key areas related to payments, commerce, identity/credentials, and security. The diagram below outlines the categories that each group will participate in as well as the phases the groups will be active in:

Web Payments Phase 1

The initial implementation of the Web Payments work will start in October 2015 and will focus on delivering standards for a Minimum Viable Platform (MVP) by December 2017.

Goals

The scope of work supports the following elements of a basic purchase triggered by user interaction with a Web application initiating a new payment. These standards define a high-level message flow for a payment from payer to payee either in the form of a credit push (payer initiated) or a debit pull (payee initiated) payment, and can be used to facilitate a payment from any payment scheme.

Web Payments Basic Payment Flow
Pre-Payment
  • Registration, by the payer with their wallet, of any conforming payment instrument they wish to use on the Web (e.g. a credit or debit card, electronic cash, cryptocurrency, etc).
Negotiation of Terms
  • Payment Initiation Request, by the payee to the payer providing the terms of the payment including elements such as the accepted payment schemes, price, currency, recurrence, transaction type (purchase, refund etc.), timeout and requests for any additional data that is required from the payee.
Negotiation of Payment Instruments
  • Discovery, by the payer, of their available payment instruments that can be used to make the payment. This is done by matching those registered by the payer with those supported by the payee (as defined in the Payment Initiation Request), while keeping information local to the payer.
  • Selection of a payment instrument by the payer, confirmation of the terms, and sending of any requested data back to the payee for validation.
Payment Processing and Completion
  • Execution of the payment by either payer or payee.
  • Delivery of a Payment Completion generated by the entity that executed the payment. This may contain a Proof of Payment if supported by the payment scheme.

The group will also address exceptions that may occur during these steps, including payment authorization failure.


Use Cases

The following use cases are in scope for phase 1 with specific limitations expressed beside each use case:

Use Case Notes
Website
Registration-less
One Time Payment
Ubiquitous Schemes
Discovery Unclear about how much wallet/payment instrument discovery flexibility should be in phase 1.
Payer Privacy The use case where the payer shares a subset of their payment instruments with the payee before the purchase is not in scope for this phase.
Manual Selection
Password Authentication
Multifactor Authentication Stretch goal for phase 1 with a focus on FIDO-based authentication and mobile phone-based fingerprint authentication.
Payee-initiated
Payer-initiated
Proofs Very basic proof of initiation of funds transfer for phase 1.
Virtual Goods
Physical Goods
Electronic Receipts Very basic receipt container and delivery protocol for phase 1.
Subscription Stretch goal for phase 1.
Basic Refund Stretch goal for phase 1.

The capabilities associated with each use case listed above can be found in the Web Payments Capabilities 1.0 document.

Groups and Scope

A list of relevant groups that will participate in the first iteration of specification creation.

Group Scope Charter
Web Payments Interest Group Continued development of use cases and requirements for phase 2. Liason between larger W3C community and other relevant standards bodies. October 2014 - December 2017
Web Payments Working Group Invoking a payment request, selecting a payment instrument, initiating funds transfer, delivering a proof of payment. Draft Charter
Web Authentication Working Group Secure authentication of entities (users, systems and devices) to enable high-security Web applications. Based on FIDO Alliance work. No charter yet
Hardware-based Security Working Group A set of Hardware-Based Web Security standard services providing Web Applications usage of secure services enabled by hardware modules (Trusted Execution Environments, Secure Elements, and other secure enablers). No charter yet.

It is currently unknown whether or not a Credentials WG or Linked Data Security WG will be created.

  • Related W3C Groups
    • Technical Architecture Group (TAG) (for reviews related to Web Architecture)
    • Security IG (for reviews about security)
    • Privacy IG (for reviews about sharing of sensitive information)
  • Related W3C Community Groups
    • Credentials
    • Web NFC
    • Web Payments
    • Web Bluetooth
    • Web Crypto API
    • Web of Things

    • Deployment and Adoption

    Deployment in phase 1 will focus on enabling a few major online retailers to run Web Payment agents to issue Web Payment invoices for processing at 1-2 major online Payment Service Providers (or banks). The payment institutions would then initiate the payment and send a proof of payment back to the retailer.

    Goals

    • 3 major online retailers launching Web Payments support (for example: Alibaba, Walmart, Target, Best Buy, Overstock.com, Amazon, Tesco, eBay, etc.)
    • 1-2 large online payment companies (or banks) launching Web Payments support (for example: Google Wallet, PayPal, Alipay, Bank of America, HSBC, US Fed, etc.)
    • 5-10 smaller players from the online retail space and the payments space
    • 1 million payments within the first year after standardization
    • Favorable reviews by the Web developer community

    Strategies

    • Deployment strategy should be a pure software deployment. Do not require new hardware to be deployed.
    • Specifications should focus on technology that has already been prototyped.
    • All software should be cloud-only for phase 1. For example, do not try to support both cloud and local wallets due to a possible conflict around the "payment message bus" being implemented at the OS layer or the browser layer.

    Unresolved Issues

    Where we need an extensible message format, we will want to specify at least a data model. The hard question will be whether we can achieve a single serialization (e.g., JSON or JSON-LD or XML) or whether we need multiple.

    What canonicalization (if any) is needed in our messages for the purpose of digital signatures.

    Acknowledgements

    The editors wish to thank the participants of the Web Payments Interest Group for discussions about and contributions to this document, as well as the Web Payments Community Group for earlier work that informed this document.