The Evolution of Payment Request API

The current charter of the Web Payments Working Group expires at the end of 2019. The Working Group plans to recharter and has been discussing scope and priorities since its September face-to-face meeting.

With rechartering in mind, I share here some thoughts on the evolution of the Payment Request API (“PR API”). Although this is not (yet) an official position of the Web Payments Working Group, I believe it represents the views of a number of participants.

The Early View

We started work on PR API in October 2015. One perspective at the time was that PR API would be “an improvement on autofill.” Browsers were already storing addresses and other information for users, and our hope was that PR API would provide a better user experience for returning stored structured data, especially on mobile.

The introductory message was: “PR API is a replacement for forms.” It seems to be low-hanging fruit to replace card payment forms with PR API, so we created our first payment method: “Basic Card.” The thinking was: if all browsers supported Basic Card, it would open the door for merchants to use PR API for other payment methods.

Basic Card was never intended to be the only payment method. There are many payment methods in the world and we never expected browsers to offer built-in support for all of them. Our vision was, and remains, that “third-party” payment handlers —Web-based or native— would be available to respond to payment requests. Indeed, Google Pay, Apple Pay, Samsung Pay, and other payment handlers work today with PR API.

As part of their implementation of PR API, browser vendors created a built-in user experience we call “the sheet.” When the merchant calls PR API and requests data, the browser pops up this view that includes the total, any explanatory strings from the merchant, user contact info and shipping addressed stored in the browser, and matching payment handlers. The user selects the relevant information and hits “Ok.” The browser then sends the selected data back to the merchant.

To summarize an initial set of expectations:

• All browsers would implement built-in support for Basic Card and a sheet to allow the user to quickly select stored data.
• Users and merchants would like the PR API experience for Basic Card, and merchants would then adopt the API for more payment methods.
• Merchants would simplify their checkout pages by having a single “buy” button rather than a potentially confusing number of payment buttons. Because the browser only shows the user matching payment handlers based on what the merchant accepts, this sheet could simplify selection.
• Third party payment handlers would plug into this ecosystem for other payment methods, either through proprietary APIs or, for Web-based payment handlers, through the W3C’s Payment Handler API.

Things did not transpire exactly so:

• Today three Chromium-based browsers feature built-in support for Basic Card: Chrome, Edge, and Samsung Internet Browser. I have not heard any plans for built-in support for Basic Card in Firefox or Safari.
• Shopify ran an experiment with 30 or so large merchants using PR API. Although checkout times dropped 30 seconds on average (a good thing), some users were surprised by the new payment sheet and did not complete transactions.
• Some payment methods include branding requirements, which could limit merchant opportunities to feature a single “buy” button.
• Similarly, payment handler providers prefer direct access to their payment handler from a button, without going through the sheet. Several of them have also said that they also store contact and address information and would like the option of returning it instead of what may be stored in the browser.

The New View

Real-world implementations and experiments have taught us a lot. Here is how I see us shifting our emphasis.

• Basic Card is Stable.
  People may still wish to use Basic Card, but the Working Group has shifted its focus to more payment methods, notably working on a Secure Remote Commerce (SRC) payment method. We have not made many changes to the Basic Card specification lately, though we may still enhance it. Although we may not see additional support for Basic Card natively in browsers, it is possible that third party payment handlers could support it.
• Explore more user experiences without the sheet. We should shift our focus from the “single buy button” view to a more conventional world where merchants continue to use payment buttons. Less functionality in the “sheet” should simplify browser implementations of PR API. We will need to continue to enhance payment handler capabilities, such as the ability for payment handlers to returned stored addresses and contact information.
• Get Handlers. Browser vendors have indicated they much prefer connecting to third-party payment handlers rather than providing built-in support for payment methods. We have also heard that a strong value proposition of Payment Request API is the ability to enable payments through native (mobile) payment handlers.

An important implication of all this is that we need much stronger support for third-party payment handlers. To that end:

• People from multiple companies working on the Chromium browser engine continue to add features to Web-based payment handlers in response to requests from payment handler providers. I’d like to express my exuberant gratitude to these engineers for continuing to innovate on this front!
• We have identified at least one payment handler-specific capability —the modal dialog in the Chromium implementation— that is potentially interesting for other use cases. Work has begun on a modal dialog proposal that could be a more general purpose Web capability. If so, it could be appealing for browser vendors to implement, and also allow us to simplify the Payment Handler APi.
• We are looking to organize some face-to-face meetings where merchants, payment service providers, browser vendors, and payment handler providers code together to produce superior PR API user experiences, or determine what is still needed. Although I am aware of experimentation by many parties with these APIs, we think a code-a-thon by Working Group participants could accelerate experiments and generate useful demos or other supporting materials.
• We will continue to work with browser vendors to increase support for an ecosystem of third-party payment handlers. To help support those discussions, we are more clearly documenting payment handler benefits; see this blog post on benefits.

Impact on Rechartering

How does this relate to rechartering?

I think the scope of our specification work will remain roughly the same. But we should adjust our priorities and initiatives to focus on PR API adoption:

• We need more browsers to support more payment handlers.
• More browser support will encourage the creation of more payment handlers.
• More payment handlers will increase the value proposition of PR API to merchants.

Although those are the dependencies, we need to work with all of those stakeholders at the same time:

• Browser vendors: What are the obstacles to supporting Web-based or native payment handlers? We have heard that removing the sheet and making the modal dialog general purpose could help.
• Payment handler developers: Other than “more support in browsers,” what features are needed? We have heard “skip-the-sheet,” “delegate requests for stored data to us,” “connect payment handlers to autofill,” and some others.
• Merchants: Other than “more payment handlers,” what is the minimum set of additional features for merchants to adopt PR API? We heard during TPAC interest in using PR API to speed up account creation, and also make it possible to create a consistent UX for cards-on-file. We need to survey merchants and get a better sense of what they would need to adopt the APIs.

With all of this in mind, the chairs and I now think that our best course of action would be to hold back on advancing Payment Request API 1.0 to Recommendation until we have more adoption. At the same time, that will give browser vendors the chance to schedule implementation of an emerging proposal to enable merchants to request pieces of an address (to reduce data exposure). This is a departure from the consensus we observed at TPAC to move ahead sooner rather than later. However, we believe that once more merchants are using the APIs, more payment handlers are available, and implementations support a new privacy feature, we will be in a stronger position to recommend the work. We plan to seek support within the Working Group for this approach over the next several weeks.

We see significant interest in these APIs and numerous parties experimenting with them. I think that securing more adoption is critical to our success under our new charter, and our planning has begun to do so.