1 of 9

Web Payments CG Proposals

Web Payments Messages, the Browser API, and the REST API

2 of 9

The Specifications

The specifications are split into messages and protocols

  • Web Payments Linked Data Vocabulary
  • Web Payments Messages
  • Web Payments Browser API
  • Web Payments REST API

3 of 9

Overall Design Direction - Messages

There should be a set of basic payment message formats for:

  • a payment instrument
    • used during registration by a payment service provider
  • a payment request
    • used to request a payment by a merchant
  • a payment request acknowledgement
    • used to respond to merchant

4 of 9

The Web Payments Messaging Specification

​

​

Examples from the Web Payments Messaging Specification

5 of 9

Message Format Design Decisions

  • JSON-based messages, not XML-based
  • Extensibility is vital - Uses JSON-LD
  • Communication over HTTPS only, non-HTTP requires signatures almost everywhere
  • Supports (at a minimum) expression of Card, Bitcoin, ACH, and ISO20022 messages
  • Non-scheme Digital Signatures are also supported

​

6 of 9

Overall Design Direction - APIs

  • There should be a browser API because:
    • it is the simplest way of driving the process in a browser
    • it is what Web developers expect

​

  • There should be a REST API because:
    • it is necessary for non-browser software
    • it is necessary for “back-end”/automated payments
    • it helps test message flexibility w/ other protocols/flows

7 of 9

The Web Payments Browser API Specification

​

​

Examples from the Web Payments Browser API Specification

8 of 9

Browser API Design Decisions

  • Promise-based flow - best practice
  • Browser mediates flow via same-origin policy
  • Decentralized discovery of payment instruments
    • Storage of payment instruments is outside the browser
    • Enables automatic discovery/syncing of payment instruments across browsers and devices
  • 100% polyfillable

9 of 9

Remaining Work

  • Steal everything the WG likes from Zach’s proposal - :P
  • Ensure in-scope flows are supported (like SEPA schemes, various ISO20022 flows, credit push, debit pull, etc.)
  • Web Payments REST API specification
  • Detail the discovery mechanism and process
  • Implement experimental minimum viable payment
  • Lots more… what else?