First Public Working Drafts of Payment Request API

The mission of the Web Payments Working Group is to make payments easier and more secure on the Web. Today the Web Payments Working Group published first drafts of specifications in pursuit of this mission:

  • Payment Request API: This specification describes a web API to allow merchants (i.e., web sites selling physical or digital goods) to easily accept payments from different payment methods with minimal integration. User agents (e.g. browsers) will facilitate the payment flow between merchant and user.
  • Payment Method Identifiers: This document defines payment method identifier strings so that components in the payment ecosystem can determine which parties support which payment methods.
  • Basic Card Payment: This specification describes the data formats used by the Payment Request API to support payment by payment cards such as credit or debit cards.

We have also published a FAQ today, and will update it as we receive questions from the community.

Although the Web Payments Working Group has begun to discuss payment application registration, we have not yet adopted a specification for this important piece of the Payment Request API suite (though there is an early proposal).

Together, these specifications will help streamline checkout in Web sites and applications. The Working Group is revising a description of how the pieces fit together and I anticipate an updated “overview” soon.

Important: These are early, incomplete drafts! We recognize that people not previously involved with W3C may be accustomed to specifications being more “mature” when they are first made public. In the W3C Process, “First Public Working Draft” does not mean that the specifications are publicly available for the first time; Editors’ Drafts are always public. Rather, it is a call for early review by the Working Group to the broader community.

In addition to hearing general feedback such as “yes, this seems like a useful overall direction” the group has a number of specific issues where we would like input, covering topics including:

  • Extensibility and versioning
  • Security and Privacy
  • How much functionality to include in the API

Issues are sprinkled throughout the documents and are being managed in the group’s issues lists (one general, and one specific to these documents). As you read the documents, we invite your comments on the issues, or you may wish to raise new issues. Please see the status section of each specification for information about how to provide feedback.

After First Public Working Draft, the Editors will incorporate Working Group resolutions into the evolving Editors’ Drafts.

In parallel, we are also studying in detail how the API will be used to addressed common payment methods. The Working Group is documenting “real-world” payment flows for payment methods such as credit cards, credit cards with 3DS, tokenized cards, SEPA credit transfers, Bitcoin, Alipay, and others. For each flow, the group expects to show how the Payment Request API fits into these payment flows. We also expect this detailed investigation to inform developer guidance on how to use the API in different scenarios and how to plan corresponding payment apps. We also expect the flows will inform our test suite development.

We welcome assistance from the community to help us document common payment flows, both those we have started to analyze and any others you feel we should address. Please see the flows home page if you wish to help.

The Working Group is currently focused on advancing the Payment Request API suite, but is also chartered to facilitate payments outside of the browser (e.g., via an HTTP API). We expect to turn our attention to that work shortly.

Today’s publications represent an important milestone for the Working Group, but we have a lot more to do to develop, test, and deploy the new API. We welcome your feedback and your help in our effort to make Web payments easier and more secure.

Approaching First Public Working Draft of Web Payments API

The Web Payments Working Group held its second face-to-face meeting at Google last week. For several months, the Working Group has been reviewing two proposals: one from the Web Payments Community Group and one from the Web Incubator Community Group. The primary goal of the meeting was to determine how turn two proposals into a single path to First Public Working Draft (FPWD). After several hours of demos, code reviews, and discussion on the first day of the meeting, we resolved to base the FPWD on the Payment Request API proposal from the Web Incubator Community Group, authored by participants from Microsoft and Google.

The decision was not easy. Both proposals have merits and supporters. Fortunately, through face-to-face time and GitHub discussions in the weeks leading up to the meeting, the differences between the proposals grew smaller and smaller. We have not resolved all of the issues, so we plan to include clear issue markers in the FPWD, currently scheduled for early April. We will invite feedback from merchants, payment service providers, developers, and other stakeholders to help us resolve these issues.

How the API Could Work

The focus of this API is to streamline checkout and help reduce shopping cart abandonment. Checkout experiences differ from site to site, require sharing the same information over and over again, frequently require many (often confusing) steps, and can be cumbersome on mobile devices. This API should make it easier and faster to pay, on desktop as well as mobile, through a harmonized experience across sites. Below I say a bit more about other deliverables from the group to improve Web payments.

Here is my current synthesis of how the standards could work. I say could because there is not yet consensus on all these points. Though preliminary and incomplete, this description should give a sense of our direction and the origin of some issues.

  • At the end of shopping on a merchant site, the user pushes the “buy” button.
  • The merchant site calls the payment API with purchase amount, currency, accepted payment methods (e.g., Visa, Paypal, Bitcoin), and any custom data for those payment methods.
  • The browser determines the intersection of merchant-accepted payment methods and user-registered payment methods (more on that in a moment). The merchant can (optionally) use the API to capture shipping information through the same user experience.
  • The user selects a payment app to pay, and carries out any app-supported activities as needed, such as authentication.
  • Assuming the payment is authorized, the payment app returns payment method-specific data through the browser to the merchant site.
  • Depending on the payment method, this data will either enable the merchant to be paid, or signal that the merchant has already been paid.

Hot Concepts and Topics

It’s worth calling out a few concepts that are in discussion and some related issues:

  • Users will pay with “payment app” software. Banks, merchants, mobile operators, and anyone else who wants to will make these available. Browsers are also likely to act as basic payment apps, storing some information on behalf of the user, as they already do today with passwords. We expect payment apps will increase security and privacy by giving users more control over what they share over the network. Payment apps will distinguish themselves through the features and services they provide beyond the standard API, such as strong user authentication, loyalty program integration, back-channel communications with the merchant for fraud analytics, and so on. Payment apps should be able to run on desktops, mobile devices, televisions and so on, but there are likely to be challenges in achieving that level of interoperability.
  • Each payment app will support one or more payment methods. We are designing the API to support the broadest possible array of payment methods. When a merchant accepts a given payment method, the assumption is that the merchant will know how to process the data returned by the payment app for that payment method. We are likely to seek to increase interoperability by standardizing some payment method response data. For example, There is an early draft of a basic card specification that describes what information merchants should expect to receive for a credit card payment.
  • Each payment method will also have an associated identifier that will be used, for example, to compute the merchant/user intersection. The group has not yet resolved the syntax of payment method identifiers and other related issues.
  • Users will register payment apps with browsers. Through registration, browsers will know which payment methods are available on the user side. We have only just begun to discuss some of the challenges associated with registration. The API will not involve sharing the user’s list of registered payment methods with the merchant.
  • For a given payment method within a payment app, a user may have multiple payment instruments (e.g., a personal credit card and a business credit card, or multiple Bitcoin accounts).

Over the next couple of months the Working Group will establish the limits of version 1 of the API. This means that some payment functionality will need to be handled by the merchant site or a payment app, at least for the short term. The group plans to keep version 1 “minimalist,” but we still have to determine just how small it will be. We want to include enough so that merchants (and their payment service providers) have sufficient incentives to adopt the API. For example, we have resolved that version 1 will support the capture of shipping information. But we are also discussing whether to include a flag to indicate a recurring payment, a flag to enable payment initiation even when the final amount is not yet known (e.g., a taxi service or hotel reservation), and whether to enable capture of some billing information to enable VAT or other tax computations on the merchant side. We plan to seek input on these issues.

We also have technical choices ahead of us, such as how to manage communications among the various parties (e.g., using events, promises, or call-backs), and how the API will support extensibility and versioning.

On Participation

We enjoyed solid participation by Web Payments Working Group participants last week, including Apple, Bloomberg, BPCE, Canton Consulting, China Mobile, Deutsche Telekom, Digital Bazaar, Federal Reserve Bank of Minneapolis, Google, IBM, INRIA, ISO 20022 Registration Authority, Knowbility, Lyra Network, Microsoft, Mozilla, NACS,, Opera, PayGate, Ripple, Visa Europe, and Worldpay. A number of guests also attended in person or by phone with additional perspectives: Capital One, DDS, Facebook, Gemalto, Intel, Netflix, Samsung, Square, and Visa.

Though we have strong representation from parts of the industry, but need greater diversity (including participation from more parts of the planet) to produce a useful API. We also need more participation because we have a lot of work to do. We need to advance the browser API specifications in order to meet our goal of early implementations before the end of 2016. Beyond the browser API and its companion specifications, we are starting to discuss developer guides on how to write Web apps (that use the API) or payment apps that support different payment methods. We will also develop a test suite for the API to promote broad interoperability. Lastly, we are chartered to develop an API for payment requests outside the browser (e.g., via HTTP or some other mechanism) for use cases such as Internet of Things payments. We will begin to focus on that work by the middle of 2016. Please contact me if you’d like to help the Web Payments Working Group make Web payments easier and more secure.

Join the Web Payments Working Group

We invite you to join the new Web Payments Working Group, launched 21 October 2015. From the press release:

[The standards from this group] will support a wide array of existing and future payment methods, including debit, credit, mobile payment systems, escrow, and bitcoin and other distributed ledger technologies. Standardized APIs (Application Programming Interfaces) will establish a foundation for simplified checkout and payment experience, greater transaction security, automated secure payments, and more payment options for merchants and users alike. These APIs will allow users to register payment instruments (such as credit cards or payment services) and select the right payment type through the browser, making payments faster, more secure, and easier, particularly on mobile devices.

Here’s how to get involved and help improve payments on the Web!

How to Participate

The technical discussion for the Web Payments WG will center around the mailing list, (archive), including minutes from weekly teleconferences and face-to-face meetings. The public may join the open technical discussions on the mailing list, though all input on the list should remain focused on the group’s agenda. Teleconferences and face-to-face meetings, as well as group decisions, are reserved for Working Group participants.

If you wish to join the Web Payments Working Group, there are 2 paths: joining as a W3C Member, or becoming an Invited Expert.

W3C Members fund the work of the group, and typically provide active resources and direct implementation experience. If you’re affiliated with a W3C Member organization:

  1. (If you don’t have any W3C Member account) Use the W3C Member account request form and get a W3C account,
  2. (If your organization has not yet joined the group) Ask your AC Representative (Member-only) to join the group using the join form,
  3. And then ask your AC Representative (Member-only) to nominate you using the nomination form.

When you have joined the group, you will also be automatically subscribed to the group’s Member-only mailing list. See the Instructions for joining the Web Payments Working Group for the details of the participation procedure.

If you do not work for a W3C Member organization, please first consider whether your employer can join W3C and get the benefits of Membership.

Invited Experts are often important to a Working Group, when they fill gaps in expertise, and when they commit to a level of participation beyond the average Working Group participant, such as acting as a test lead, a specification editor, a reliable scribe, or a chair. If W3C Membership is not an option, and you have the expertise and commitment to participate, please contact the staff contact, Doug Schepers.