2018 in Web Payments

In December 2017 I wrote a blog post on the progress of the Web Payments Working Group and called out two 2018 objectives in particular:

• “Broad deployment of browsers that support Payment Request by mid-2018.” Chrome, Safari, Edge, and Samsung Internet browser all ship support for Payment Request; Firefox nightly began shipping with some support as well.
• “Early reports [from merchants about Payment Request] are promising, but our experience is still limited.” We now have some results via the Shopify experiment and J.Crew findings. The findings are encouraging (faster checkout) but indicate further adjustments and user experience optimizations will help.

Beyond those two objectives, I want to highlight this 2018 progress:

• In 2018 Chrome began to ship support for Payment Handler API, an important avenue for payment method innovation. This has led Barclays, Capital One, Coil, Credit Suisse, Facebook, Google, Klarna, Lyra Networks, Shopify, Worldline, Worldpay and others to experiment with the payment handler side of the Web payments ecosystem.
• EMVCo’s publication of version 0.9 of Secure Remote Commerce (SRC) in October prompted the Working Group to reorganize its card payment security discussions on tokenization and 3-D Secure. Since then, we have been discussing how to integrate SRC and the Payment Request ecosystem. Nick Telford-Reed paints a helpful and encouraging picture in his blog post on SRC and Payment Request. I anticipate that in 2019 we will begin to flesh out what one or more payment methods could look like to facilitate SRC integration.
• We became more familiar with European open banking API development through growing collaboration with the Berlin Group, STET, and Open Banking UK. I am now optimistic that we will revive our work on credit transfer payment methods in 2019.

I expect the Working Group’s priorities in 2019 to be:

• Publish Payment Request API (version 1.0) as a W3C Recommendation and begin implementation of the next round of features. For example, we recently discussed adding a hasEnrolledInstrument method so that merchants can determine whether their customers are ready to pay through a “frictionless” checkout experience. This would complement the existing canMakePayment method.
• Develop and create experiments for one or more SRC-related payment methods.
• Develop and create experiments for one or more credit-transfer payment methods in the context of PSD2 in Europe.
• Promote implementation of Payment Handler API in more browsers, and work with payment handler developers to solidify the specification.

In addition, it will also remain important that we raise awareness of Web payments among merchants and users, understand any obstacles to adoption, and report success stories.

I will also be interested to see whether we start discussions about payment methods related to real-time payments or distributed ledgers.

Many thanks to the Web Payments Working Group for their contributions and productivity this year. In particular, I wish to express my appreciation for the leadership of co-Chairs Nick Telford-Reed and Adrian Hope-Bailie. Many thanks to the engineers from Google, Samsung, Mozilla, Apple, Microsoft, and others, but especially to Marcos Caceres, who has done so much to advance the group’s specifications and improve the quality of all implementations through the test suite.

I look forward to making progress on Web payment implementation, adoption, and increased security in 2019.