The agenda of the recent Web Payments Working Group meeting (19-22 October) spanned three broad topics:
- Payment Request API, today and tomorrow
- Streamlining authentication in payments flows
- QR codes and more payment methods
Meeting minutes are linked from the agenda; below is my summary.
Payment Request API, today and tomorrow
We first discussed a plan to finalize Payment Request 1.0: it has shipped in Chromium and Webkit browsers for several years; can be used with Apple Pay, Google Pay, Samsung Pay; and is supported in several merchant libraries (e.g., Stripe and Braintree). After the meeting (and a Call for Consensus) the Chairs announced the decision to proceed toward Recommendation. Version 1.0 provided us with a lot of insights and now we can build on that experience.
Streamlining authentication in payments flows
We then discussed “next version” Web payment capabilities, some of which are already in development. In particular, we saw demos of Secure Payment Confirmation (SPC), designed to streamline strong authentication during checkout by marrying Payment Request and Web Authentication. Here’s how it works: Web sites call SPC with Web Authentication credentials as input. If the browser is able to authenticate the user using any of the (previously enrolled) credentials, it will prompt the user and return the resulting assertion to the site. In addition, SPC is designed to support “transaction confirmation” use cases, such as those described in European regulation (PSD2’s “dynamic linking”). SPC features a clear and secure display of key transaction details, reduces the total number of user gestures to authenticate, and eliminates the need for the site to open its own window for Web Authentication. Stripe showed a demo that leverages the preliminary implementation of SPC in Chrome 86. The demo is part of a pilot program that Stripe is running to test the hypothesis that users will prefer a low-friction authentication experience using Web Authentication (as part of an EMV® 3-D Secure step-up) to a typical one-time password experience. We look forward to hearing results from the pilot by early 2021.
We then heard from Visa and Mastercard about how SPC could enhance the user experience of EMV® Secure Remote Commerce (SRC) flows. (I apologize for the similarity between “SRC” and “SPC”!). Visa presented slides that show an SRC checkout demo including SPC leveraged by the merchant’s payment service provider. Mastercard shared mockups of an SRC checkout where a Web-based payment app uses SPC to streamline authentication.
My colleague from Mastercard referred to these approaches respectively as “the left side” (code running in the merchant site) and “the right side” (payment app code running on the user’s device). I appreciated that imagery, which I have similarly expressed in a Payment Request ecosystem diagram (shown in this post) where the merchant site (calling Payment Request) is on the left, the browser is in the center, and payment apps (native or Web-based) are on the right.
We thus heard calls for SPC to be available for both left side and right side solutions. We have heard similar requests related to another user experience enhancement: “in-context display”. Today the Chrome implementation of the Payment Handler API includes a “modal window” in which payment app code runs. Chrome displays the origin of the code running in the window at the top, a security benefit. There is general agreement that this modal window, which appears above the underlying merchant context, provides a better user experience than a redirect. In-context display is thus available today on the right side, but not yet on the left. I anticipate we will turn our attention increasingly in 2021 to left side use cases as we continue to revisit Web payments architecture.
To round out our authentication discussion, the co-Chairs of the Web Authentication Working Group gave us an update on the progress of Web Authentication Level 2.
QR codes and more payment methods
We also discussed the following payment methods and use cases, looking for connections to Payment Request, SPC, and our architectural considerations:
- QR codes: QR codes are very popular in some parts of the world, and have gained more attention during the COVID-19 pandemic as a way to communicate at a distance. We heard first from EMVCo, who is developing some new standards in this space. We also heard from two entities that are making use of that work: China Union Pay, and the European Payments Council on Mobile Initiated SEPA Credit Transfers. Our colleagues from Entersekt also shared perspectives on QR codes and Web payments, and these may help us structure our conversations moving forward.
- Open banking: Colleagues from STET and the Berlin Group provided updates on the adoption of their open banking APIs, some challenges they are facing, and some new programs they expect to appear in 2021.
- Web Monetization: Coil (one of the TPAC sponsors, thank you!) shared updates about Web Monetization deployments and a current strong interest in using it for use cases such as tipping and donations. We also learned more about the Grant for the Web, a Coil-led project to boost innovation around Web monetization.
- Real-time Payments (RTP) and bill pay: The Clearing House described advances in the Real-Time Payments (RTP) protocol as well as a bill pay use case where the Payment Request architecture could be a good fit for enabling streamlined checkout using the “request for payment” functionality developed alongside RTP. We also connected this discussion to our QR codes and authentication discussions.
Although I longed to see colleagues in Vancouver, I found this meeting invigorating and productive (as I found our April 2020 meeting). There is a lot of experimentation happening right now, and I look forward to hearing the results in early 2021, and of course sharing them in this forum.
Thanks to the Web Payments Working Group participants for all they do!
A few days ago we launched a new Merchant Business Group focused on non-technical discussion and advocacy. The group held its first meeting in late October and I hope that soon we’ll connect some of their use cases and requirements to the Web Payments Working Group agenda. Contact Nick Telford-Reed or me if you have any questions.