Preparing to Advance Payment Request and Payment Handler APIs

Fifty people from more than 25 organizations attended the 23-24 March face-to-face meeting in Chicago of the Web Payments Working Group. We wanted to know whether we are ready to advance our most mature work to the next stage of the W3C Process, and whether we are ready to take up new work that complements it.

The first day was a blast, which is uncommon praise for a day-long meeting. What made it exciting for me was the evidence of traction. The editors of the Payment Request API brought us up-to-speed on the main changes of the past several months. We then heard about implementation experience from Google and Facebook, and enjoyed demos from Facebook, Samsung, Worldpay, Alibaba, Microsoft, and Gemalto. The demos brought the specifications to life and reinforced a shared vision. The number and diversity were very motivating.

Most of first day focused on Payment Request API, which enables merchants to build streamlined checkout flows where people can easily return card information stored in the browser.

Some Payment Request API implementers have also begun to support payments by native mobile apps in addition to browser-stored credentials. We call these “third party payment apps” and the consensus is that this architecture should support integration of third party payment apps. So in the afternoon of the first day we turned our attention to the Payment Handler API draft. That specification defines capabilities that enable Web applications to be “third party payment apps” and handle payment requests. The task force working on that specification has made significant progress in the past few months thanks to growing contributions from Mozilla, Google, Opera, Shopify, Ripple, Worldpay, Klarna, Samsung, American Express, and others.

Views differ on how strongly coupled Payment Request API and Payment Handler should be. Those views were on display on Day 2, and we proceeded at a slower pace. I would summarize them this way:

• Strong Decoupling. Payment request API can be implemented in browsers and other user agents without requiring third party payment apps. It is being implemented, and it should be allowed to progress through the W3C Process without dependencies on Payment Handler API.
• Moderate Decoupling. Payment request API can be implemented in browsers and other user agents without requiring third party payment apps, but there is a clear expectation for third party payment apps to be part of the ecosystem. Therefore, we should get implementation experience for Payment Request API and also third party payment apps. Payment Request API should not be finalized in the W3C Process until we are confident the two play well together.
• Moderate Coupling. We won’t know whether Payment Request API is stable until we have greater implementation experience with Payment Request API. Therefore, we should get more implementation experience for both specifications and the two should exit the “Candidate Recommendation” step of the W3C Process at the same time.

Although people in the group likely have more nuanced views than this, I think it helps frame our discussion. In the end, we opted for a moderate decoupling: Payment Request API can exit Candidate Recommendation once we’ve satisfied our implementation expectations —two implementations from two different vendors on both mobile and desktop— and will not depend on the status of Payment Handler API. However, the group will simultaneously gather third party payment app implementation experience during the Payment Request API Candidate Recommendation phase to strengthen our confidence. Discussion about requirements and expectations took up several hours but it was important that we hear from one another and come to agreement on our plan.

We did cover a number of other topics on the second day:

• We discussed a draft Tokenized Card payment method specification. Although people did not rally around the draft we presented, they did voice significant interest in defining one or more tokenized card payment methods. I expect this activity to pick up momentum because it offers an opportunity to make Web payments more secure with little added friction.
• We also discussed a Basic Credit Transfer payment method specification. People also indicated interest in this specification both because of its adoption in some places (e.g., we heard 30% of Internet payments in Belgium are done through credit transfers) and because it is a “push” payment method, which helps us validate the Payment Request API for more payment methods than cards. The group asked the task force working on this specification to find more implementers and validate the usefulness of the specification across a variety of credit transfer systems.
• We also discussed a new proposal to give payment method owners the tools they need to securely authorize payment apps that implement those payment methods.

The Working Group is thus preparing to answer two questions over the next couple of weeks:

• Should Payment Handler API advance to First Public Working Draft?
• Should Payment Request API and its supporting spec Payment Method Identifiers advance to Candidate Recommendation?

For Payment Handler API, the road to First Public Working Draft is a bit easier. If all goes well, I would expect that to happen in April. We won’t have resolved all the issues by then, but we don’t have to: we will record them in the specification and those markers will help us guide reviewers.

For Payment Request API, we need to freeze the issues list and resolve at least some of those issues before the Chairs issue a call for consensus. If all goes well, I would expect we enter Candidate Recommendation by mid May.

Many thanks to Adam Roach for his photo of the group meeting. Minutes from 23 March and 24 March are available.

Congratulations to the Working Group for their significant progress and upcoming milestones!