July Payments Recap

In April the Chairs of the Web Payments Working Group enumerated several priorities for the medium term. In this post I summarize our progress since then.

Get Payment Request API to Proposed Recommendation

Browser makers continue to implement and deploy Payment Request API. I am very excited about support in the Firefox nightly release anticipated mid-August.

At our April meeting in Singapore we identified some key features for consideration in the first version of Payment Request API. Since then, the editors have made progress on a number of them, including:

• Support for a retry() method. This is a valuable user experience enhancement. If there are errors in the Payment Request API response data, the retry() method enables the merchant to signal them to the user (and ask for corrections) without closing the browser’s user interface.
• A new mechanism to support payment methods (such as Apple Pay) that include a merchant validation process.
• Enhancements to the API to support billing address capture for on-the-fly tax computations. Up to now, billing address information has been managed by payment handlers, so that it was not available to merchants for tax computations (e.g., when goods are not shipped) until after the payment had been completed. Now merchants can update totals with tax information while the browser interface is open.
• Support for “store cards,” which are supported by Apple Pay and might be supported by other payment handlers.

The editors have also made significant progress on a test suite. Marcos Caceres announced a draft implementation report that will be useful in demonstrating interoperability as part of advancing the specification to Proposed Recommendation.

In light of more substantive changes to the specification, the Working Group republished the 16 July 2018 Candidate Recommendation of Payment Request API, with an expectation of advancing to Proposed Recommendation no sooner than 31 October 2018. We have some work to do to bring all the implementations in line with the updated specification. We are, however, making good progress on closing the issues to exit Candidate Recommendation.

Web-Based Payment Handlers

In exciting news for Web-based payment handlers, Google announced in June that Chrome 68 Beta will ship with support for Payment Handler API. We have also heard from Samsung that they anticipate supporting the API in Samsung Internet Browser. My understanding is that Mozilla also anticipates supporting the API, but is currently focused on completing their Payment Request API implementation.

We have a healthy issues list associated with Payment Handler API, but our discussions have slowed a bit since April. I hope to see activity resume this month.

Card Payment Security

Three topics fall under this banner: card tokenization, strong user authentication, and the Secure Remote Commerce (SRC) work of EMVCo.

We have made significant progress on our Tokenized Card Payment specification, which, though still drafty, is nearly ripe enough for experimentation. That specification depends on another specification for which we have published a first draft since Singapore: Payment Method Encryption. We intend this to be imported by any payment method where all or part of the response data should be encrypted. I would love for security experts to look at that very early work and help us make progress. The specification leverages a limited profile of JSON Web Encryption.

Regarding strong user authentication, there are two threads:

• How does Payment Request API relate to EMVCo’s 3-D Secure 2 specification?
• How can we leverage Web Authentication (Web-based payment handlers) in 3-D Secure 2 flows?

Since April, we have made available a very early draft of a 3-D Secure 2 with Payment Request API specification. At this point, the specification only describes at a high level what might be required for a payment handler to be able to initiate 3DS2 flows, namely: a signal from the merchant that a 3DS2 flow is requested, some data about the merchant, and the response data the merchant will receive after the payment handler has taken the user through 3DS2 flows.

In parallel, we have increased our communications with and between the Web Authentication Working Group, FIDO, and EMVCo and are looking into ways to do so more systematically moving forward.

Meanwhile, EMVCo has made progress on their Secure Remote Commerce (SRC) specification, and many people have asked me about the relationship to Payment Request API. I look forward to having a crisp answer as soon as SRC becomes publicly available.

We intend to make progress on tokenization and 3DS2 in the meantime, but my guess is that we will have a much clearer picture of how the pieces will fit together once SRC becomes public. I very much hope that happens before October so that we have a chance as a Working Group to develop a plan while face-to-face in Lyon.

Push Payments and PSD2 in Europe

Another exciting development over the past two months has been the creation of demos from Worldpay, Worldline, and Lyra Networks that show how to piece together multiple open APIs — Payment Request, Payment Handler, Web Authentication, and Open Banking UK— for streamlined, secure push payments. I am hoping to publish video of at least one of these demos very soon.

I have been in discussion with representatives from different European open banking API efforts (Open Banking UK, the Berlin Group, and STET) and have invited them to participate in our face-to-face meeting in Lyon and help ensure interoperability among the various efforts.

Looking Ahead to TPAC 2018 in October

I have mentioned a number of topics already that I expect to be on the October agenda:

• Status of Payment Request API issues, implementations, and test suite reporting
• Secure Remote Commerce, 3DS, tokenization, and the relation to Payment Request API. We also have an opportunity to have a joint meeting with the Web Authentication Working Group, which convenes on the same days as the Web Payments Working Group.
• Open banking APIs and Payment Request API
• Increasing payment handler implementations and addressing open issues

In addition, we are likely to continue to discuss merchant adoption. Recently colleagues at Facebook, Google, Samsung, and Mozilla revived the issue of creating a visual identity for Web Payments. I am hoping we have some designs to review at TPAC.

If you are planning to use any of these Web payments APIs for your site or payment handler, please let me know!