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, NIC.br, 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.