A Way Forward
These various forces suggest a few main themes for a way forward.
Embrace the App part of Payment Apps
Installing a mobile app is now a familiar experience. The Progress Web App (PWA) approach attempts to make Web applications more app-like (for both mobile and desktop). By moving payment apps more in this direction, we think we can solidify user acceptance of payment app lifecycle management, and solve some of the UX challenges raised by changing browser behaviors.
The user relationship with an app begins with a registration ceremony through the browser’s UI. Although there are some concerns about adding friction to the user experience of payment app registration, we think explicit registration ceremonies can simultaneously mitigate several of the risks described in the privacy threat analysis and provide a better user experience overall.
Before describing a few ideas for registration ceremonies, here are some of the activities it could include:
- Requiring a user gesture before a payment app can be invoked automatically (skip-the-sheet).
- Granting first-party storage access. This level of access could enable a payment app to recognize the user (through Web Authentication or other means) and maintain a session as the user makes use of the payment app across origins.
- Giving the user the option of installing a launch icon (on mobile or desktop) – and integration with browser settings, allowing users to more easily find and manage their registered payment apps.
It is our expectation that the user experience of interacting explicitly with a payment app will be superior to alternative checkout implementations such as iframes that require the same types of consent. In addition, we think it will create better outcomes because a user is more likely to be comfortable granting privileges to a known app than to an unfamiliar piece of code embedded in a web site.
We are likely to see a variety of payment app registration ceremonies, both during a transaction and outside of a transaction. Here are some ideas; the first two are already deployed:
- On a site that distributes payment apps (e.g., our fictitious bobpay.com), the user clicks the “Get Bobpay!” button, which prompts the user confirm registration.
- During a transaction, the browser offers a payment app for just-in-time registration. The user selects it, which prompts the user to confirm registration.
- In the browser’s settings, the user can easily add and configure payment apps. Indeed, much in the way that browsers out of the box list a few well-known search engines but allow the user to add others, we’d like to see browsers list a few well-known payment apps out of the box. Browsers could provide very streamlined UX —like a single checkbox— for registering a payment app, granting first-party access, etc.
One key to these ceremonies or others will be the quality of the UX provided by the browser. One aspect of that quality may well be how well payment apps integrate into the overall app model of a given platform.
Combine Web Authentication and Web payments
The Web Payments Working Group and Web Authentication Working Group jointly discuss payments use cases. We have reviewed several proposals that we think will improve transaction flows:
- A Web Authentication Level 2 feature allowing cross-origin iframes (e.g., code from a user’s bank embedded in a payment handler distributed by another party) to retrieve (but not create) Web Authentication credentials. This should allow code embedded in a payment handler (such as issuing bank code) to authenticate the user during a transaction without requiring a full-page redirect to another site. We think that staying near the merchant checkout context is a superior user experience than a full-page redirect to another site.
- An enhancement to Web Authentication that enables a relying party to create Web Authentication credentials usable by itself and another origin. This feature would enable, for example, a payment handler to control the authentication experience for the user, using credentials minted by the user’s bank. The payment handler could verify the authentication for its own purposes, then pass the same credentials to the issuing bank for its own purposes. In other words: less user interaction with all the trust (by two different parties involved in the transaction).
- A proposal to leverage the combination of Payment Handler API and Web Authentication to fulfill transaction confirmation use cases (e.g., part of PSD2 regulation).
- A proposal to use the same user gesture for two purposes: initiate Web Authentication and launch a payment handler.
For all of these, we seek to take advantage of Web Authentication in payments flows. The last two push the relationship further and thus would require some API changes grant special powers to payment handlers.
Session Persistence: More Discussion Required
Browser behaviors around storage (e.g., clearing storage automatically after a certain number of days, limiting third-party cookies) are likely to affect session persistence. This means that users are likely to have to log in on more sites, and more frequently, adding friction to checkout and raising the risk of card abandonment.
We are currently trying to figure out whether payment handlers can be empowered to enable greater session persistence in ways that benefit the user, by building on the trust relationship the user establishes with the payment handler via explicit lifecycle management.
I’ve heard the following goals:
- Make it very easy for users to log in. One way to increase session persistence would be to make it harder to clear cookies, but that strategy is not likely to gain traction with browser vendors. Therefore I am trying to emphasize making it “easier to get in” instead of “harder to get out.”
- Improve security by not relying on cookies, which are exfiltratable.
- Make it easy for users to consent to sharing information across origins for payments.
- Minimize the need for user interaction.
Some of these things can be done today, such as one-click login using passwords stored in the browser, and Web Authentication for password-less login. Neither of those relies on cookies (point #2). Stored passwords are distinguished from cookies in the browser UX to clear stored data, and can thus be made more persistent than cookies.
New APIs are emerging that may also help, including the Credential Management API (to automate logins under some conditions).
We need to do more collaborative work with the payments industry to document requirements, and then to map those to both current and new technologies.
Code-a-thon!
We think that adoption of these proposed features would add great value to payment apps for a variety of payment flows. To prove it to ourselves, the Web Payments Working Group is running a virtual code-a-thon later this month. I look forward to seeing cool innovations and demos, and to sharing them in this forum in early June.
Before I go, I’d like to again thank all the engineers who are contributing to improving payments on the Web! And many thanks to Marcos Caceres and Danyao Wang for feedback on this post.