Web Payments Working Group

A few days after the Brexit vote, I traveled to London for a face-to-face meeting of the Web Payments Working Group. I was unsure what chaos I would find. Friends suggested I might find great deals due to currency devaluation. I found neither chaos nor deals, mostly because I was in meetings nearly the entire trip. But the shock of the outcome was palpable, mostly as uncomfortable humor.

On the other hand, I felt the mood in our meeting was largely optimistic. In particular:

• New people from a growing set of organizations signed up to do work. I took this “diversification” as a good sign of traction and investment.
• We also heard more about implementations, another good sign of traction (and source of insight about the work). One takeaway is that some of the browser makers have indicated their expectation that the payment request API would be available in browsers for the Q4 2016 holiday (shopping) season.

Here were a few other key topics we covered during the meetings:

• The payment request API provides a core functionality that involves matching merchant-accepted payment methods with user-provided credentials, but it does not itself include support for third party payment apps. Those are apps that we expect banks, retailers, mobile operators, card networks, and others to provide so that users can store credentials and make payments alongside value-added services. To add third-party payment apps to the ecosystem, the Working Group agreed to work on Payment Apps API, which is still very drafty. We have many open questions about registration, selection, display, and launch of these apps, as well as how to ensure the best possible user experience so that merchants will have confidence that apps will help increase conversions.
• Several participants reported on their security review of three WG specifications; this prompted a call for further security review, and several people volunteered to ask their organizations to commit to those reviews.
• One of the ways that we have sought to validate the usefulness of this approach for “real world payment systems” has been to document the information flows of those systems and the inputs and outputs we would expect from a payment app that supports them. In addition to the “Basic Card” payment method specification we published in April, we discussed SEPA Credit Transfer, Alipay, and Samsung Pay at the face-to-face meeting. One design goal is to make it possible for anybody to publish a payment method description to tell people how to use that payment method with the payment request API. We realized the need to provide some good practice suggestions for people who want to create payment method documentation.
• We also began to look at and take up specifications for payments outside the browser (e.g., in an Internet of Things context). (We had previously resolved that this work, in scope for the Working Group, would have a lower priority than the browser APIs.)

While I felt good about our progress, we definitely have more work to do, to close issues around payment request API, to develop a test framework, to build a shared understanding about how third-party payment apps will work, and to figure out how to bootstrap the ecosystem. In particular, we need to ensure that the user experience is as simple as possible, and that merchants have sufficient motivation and confidence to adopt the API.

The group meets next in Lisbon in September, during W3C’s annual TPAC meeting. At that meeting I hope that we will have the pieces in place to advance payment request API to Candidate Recommendation, that will see some advanced demos, and that we’ll have a solid payment app specification that the entire group can support.

For additional personal insights from co-Chair Adrian Hope-Bailie, see his post Reflecting on the W3C Web Payments WG.

Photo Copyright Adam Roach

Today we announced the July 7-8 Face-to-Face meeting of the Web Payments Working Group, in London, hosted by Visa Europe. We’ll be building the agenda over the next few weeks.

The following FTF meeting of the group will be the week of 9 September in Lisbon at TPAC 2016.

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.