Following TPAC 2019 discussions last October I summarized how the Web Payments Working Group’s vision of Payment Request had been evolving based on experimentation, implementation feedback, and discussion.
Now it is time to share a new vision for payment apps, one driven by a host of changes on the Web, including our experience with Web payments APIs. These changes give us an opportunity to provide superior checkout experiences through payment apps compared to other Web technology.
Before we get started, here’s a quick reminder of some terms:
- In the Payment Request architecture, the user interacts with a payment app to respond to the merchant’s request for data.
- Payment apps today come in three flavors: built into the browser, native mobile, and Web-based. We call the latter two “third-party payment apps.”
- The Working Group is defining the Payment Handler API as a standard way for Web-based payment apps to register and interact with browsers. Thus, a payment handler is (1) a Web-based payment app that (2) responds to Payment Request API.
- A preliminary version of the Payment Handler API (a draft) ships today in Chromium browsers.
For a summary of some current benefits of payment handlers, see my October 2019 post on the payment handler value proposition.
Recent Chrome Enhancements to Support Payment Apps
The Chrome team has been very active over the past six months improving payment apps. (Thank you Chrome Team!) The October post included two points related to payment apps:
- The “sheet” is the browser supplied UX for accessing browser-stored addresses and contact information, and for selecting a payment app when more than one is available. The Shopify experiment with payment Request suggested that the sheet surprised some users. This was also borne out by Mozilla’s internal research on their own implementation of “Basic-Card.”
- Experimentation has led browser vendors to conclude that the people closest to the details of a given payment flow should build that experience. For this reason, browser vendors are now focused on providing the “pipes” to enable excellent third-party app experiences. Indeed, realizing this in 2018, Mozilla abandoned their work on the Basic Card implementation. Similarly, in January 2020, the Chrome team followed suit and announced plans to gradually remove their build-in support for Basic Card.
Regarding the sheet, we have also heard from potential payment app providers that they would like to manage and return user contact and shipping address information and would like to manage it instead of the browser. The Chrome team therefore proposed a means to delegate requests for shipping address and contact information to payment apps.
The Chrome team has also continued to improve two payment app features:
- Just-in-time registration, which facilitates payment app distribution.
- Skip-the-sheet, which improves the user experience by automatically launching a payment app under appropriate conditions such as when only one is suitable for a transaction. We have also been discussing user configuration of a “preferred payment app,” which would enable automation in more scenarios.
Thanks to these changes, we are exploring a few streamlined user experiences that do not involve the sheet. They start when the user clicks a payment button, after which:
- If the user has only one matching payment app, the browser launches it automatically.
- If the user has more than one matching payment app, the browser displays an app selector instead of the sheet. Co-Chair Adrian Hope-Bailie created a presentation on the app selector approach last October. A key point of this presentation is that there is precedent for this type of user experience (see also the Web Share API). Thus, there is some expectation that app selection will be less surprising than a “sheet” experience.
Sample Web Share user experience
In both flows, the payment app can open a Window for user interaction, then return data to the merchant. We have started discussions of a third flow:
- If the user has only one matching payment app, and the payment app has registered with the browser its ability to do “authentication only”, then the browser automatically performs biometric or OS-level authentication. The user authenticates, and the browser passes the results (the “authentication assertion data”) to the payment app. In this scenario, the payment app does not open its own Window. The entire user experience —display of total amount and other transaction information, and the prompt for authentication— is managed by the browser.
This last flow in particular is likely to make payment apps the best user experience on the Web: you push the buy button and then authenticate and you’re done. By leveraging payment apps and authentication together, we thus have the opportunity to simultaneously improve usability, privacy, and security.
One last comment about the sheet before we move on: if you have use cases that benefit from the sheet, please let us know!
Minimal UI Flow
Browser Changes that Affect Payments
In parallel with our work on Web payments, browsers are changing in other ways that have an impact on payments. As a result, we are investigating which additional capabilities payment handlers might need to enable streamlined checkout in light of these changes.
Restrictions to Cross-Origin Sharing and Storage
To enhance user privacy on the Web, browser vendors are moving quickly, and with some unity, to restrict cross-origin data sharing and to clamp down on any form of browser fingerprinting. These initiatives include standardization activities (e.g., automatically blocking third-party trackers, requiring remote origins/iframes to explicitly request first-party storage access, etc.) to help harmonize these new browser behaviors.
In the payments ecosystem, merchants often rely on payment service providers who include code via iframes in merchant pages. Because of these browser changes, this third-party content will lose cross-origin access to information stored in the browser (e.g., via cookies or indexDB). My understanding is that a big motivation is to reduce tracking (especially as is done today to enable targeted advertising). However, these browser changes will also have an impact on other scenarios such as risk assessment during a payment. Browser changes may potentially break existing code such as EMV® 3-D Secure implementations. For this reason, the Chrome team recently discussed changes to SameSite behaviors with the Web Payments Working Group and presented some mitigation strategies.
I do not think we have a clear vision of the path forward. A variety of groups are discussing use cases to inform designs.
Privacy as a Priority
Beyond changes to storage, browsers are taking further steps to improve user privacy, so we have been tracking conversations on trust tokens, efforts to reduce fingerprinting, and others.
The Chrome Team also developed a privacy threat analysis of Web payments APIs. This led to a series of proposed changes to payment apps to reduce the risks of cross-site tracking, fingerprinting, and unnecessary data sharing.
The mitigation strategies we have discussed —raising user awareness about the role of the payment app, ensuring that default behaviors protect user privacy, and others— also contribute to our emerging vision. For example, the Chrome team is researching privacy improvements such as UI treatment to raise user awareness when sharing data from a payment handler with an ecommerce site.
Web Authentication is Now Widely Deployed
Meanwhile, Web Authentication —half of FIDO2 along with the CTAP spec— is now shipping in all major browsers with more and more authenticator support, all very exciting. Because strong customer authentication (SCA) plays such an important role in payments (e.g., under PSD2 regulation in Europe and in 3-D Secure flows), we are having a lot of discussions about how to combine Web Payments APIs with Web Authentication to optimize the user experience of some payment flows.
If you’d like to help raise awareness about Web Authentication, please consider joining the WebAuthN Adoption Community Group.