BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News W3C Web Payments HTTP Specification Working Drafts Released

W3C Web Payments HTTP Specification Working Drafts Released

Bookmarks

The Web Payments Working Group released working drafts for Web Payments HTTP API 1.0 and Web Payments HTTP Messages 1.0 on September 15, 2016. The working group is welcoming feedback on these early drafts.

The charter for the Web Payments Working Group is to standardize high level flow, APIs and message schemas for web payments. The benefits of standardization are enlisted on the charter goals:

  • A better checkout experience for users, particularly on mobile devices. The standards should facilitate automation, one approach to improving the user experience.
  • Streamlined payment flow, which is expected to reduce the percentage of transactions abandoned prior to completion ("shopping cart abandonment").
  • Easier adoption of payment instrument improvements (e.g., related to security) or new payment instruments.
  • Added value through machine-readable digital payment requests and payment responses.

One should start with the Web Payments API draft and follow it up with the Web Payments Messages draft. The proposed APIs are CRUD style Web APIs. The proposed messages are represented as data models that can be expressed in any schema language. For the purposes of demonstration, the example messages are in JSON format.

The currently documented high level web payment flow, displayed below, depicts a pull payment flow but the specification also supports push payments. It has primarily three phases: payment app registration, initiating a payment request and generating a payment response.

The payment mediator is a new concept, which traditionally did not exist. As the name suggests, it co-ordinates the flow of messages between payee, payer and selected payment app. It is this component that intelligently routes the payment request based on whether it is a push or pull payment. It also determines which payer payment apps can be used based on the payee's accepted payment methods.

There are clearly a number of interesting challenges to address that includes:

  • The 420 HTTP status code is undefined.
  • Relevant error response HTTP status codes. Apart from the multiple possibilities arising from existing digital payment systems such as ACH, credit card and cryptocurrency, it needs to support future digital payment methods.
  • Threat matrix. Some of the newly introduced sensitive operations are:
    • payer's HTTP client authenticates itself for registering a payment app from the payment service provider's site.
    • payment mediator's actions.

Rate this Article

Adoption
Style

BT