Further Streamlining the Payment Request User Experience

Over the past few years the Web Payments Working Group has discussed ways to streamline the Payment Request API user experience when it comes to payment handlers. Two ideas are now available for experimentation in Chrome:

For both of these features I want to introduce the term “sheet.” When the user activates Payment Request API (e.g., by clicking on a “Buy” button), the browser shows a browser-owned window for the user to select stored data. We call this window “the payment sheet” or “the sheet.” I am not sure who coined the phrase, but I first heard colleagues from Shopify utter it.

Just-in-time Registration

In the Payment Request ecosystem, users pay through payment handlers. Payment handlers include Web pages, native digital wallets, and even the browser (when storing credit card information). In the sheet, the browser displays relevant payment handlers based on payment methods accepted by the merchant. How does the browser come to know what payment handlers the user has?

The first mechanism is manual installation: the user downloads a digital wallet from a native store, or clicks on a button on a Web site to register a Web-based payment handler. In the case of Web-based payment handlers, the registration happens through Payment Handler API, supported as of Chrome 68.

Chrome engineers have also deployed a second mechanism: “just-in-time” registration for payment methods that are identified by a URL. It works as follows:

  • The merchant identifies accepted payment methods by URL in their call to Payment Request API.
  • If the user has not yet registered a payment handler for these payment methods, the browser looks for a Payment Method Manifest at the same origin (i.e., domain) of the payment method URL. If the browser finds instructions for registering a payment handler in the Payment Method Manifest, it offers that choice to the user (via a name and icon). In other words: the party that controls the payment method authorizes which payment handlers can be used for the payment method and provides code to the browser for automatic registration.
  • Note that at this point, the payment handler is not yet active; it does not receive events, for instance. However, upon user selection, the browser registers the payment handler and launches it. Of course, the user may need to create an account with the service accessed through the payment handler.

To me this is an innovative approach to payment handler distribution and I expect it will help us bootstrap the payment handler ecosystem.


Under certain conditions, it is possible to “skip” the sheet and jump right to a payment handler, thus eliminating one user gesture. I realize the phrase “skip-the-sheet” sounds like kids’ board game. I welcome suggestions for a catchier name.

In Chrome’s implementation here are the conditions for the skip-the-sheet experience:

  • The merchant indicates support for a single payment method in Payment Request API. That payment method must be identified with a URL.
  • The merchant does not request information that is only available through the sheet, namely shipping address and contact information. Thus, this might be useful when purchasing digital goods.
  • Either:
    • The user has exactly one payment handler installed for this payment method, or
    • The user has no payment handler installed for this payment method but the payment handler can be registered through just-in-time registration.

When these conditions are satisfied, a user gesture (such as clicking the “Buy” button) will trigger Payment Request and the browser will skip the sheet.

Enable the features in Chrome

To enable these features (in a version of Chrome where they are available) use these flags:

  • Service Worker payment apps with chrome://flags/#service-worker-payment-apps
  • Just-in-time service worker payment app with chrome://flags/#just-in-time-service-worker-payment-app
  • Web Payments single app UI skip with chrome://flags/#enable-web-payments-single-app-ui-skip

After changing the value of a flag, restart your browser.

Try it out

Rouslan Solomakhin has made available some test pages for these features. For just-in-time registration:

  • Ensure that you have not yet registered the (fictitious) BobPay payment handler. On the BobPay home page, the text “Install Web App” in the upper right hand corner of the page means you have not yet registered the payment handler.
  • Visit this demo site that accepts BobPay.
  • When you click on the “Buy” button, you will see BobPay as one option to pay even though it is not registered.
  • If you choose it to pay and then visit the BobPay payment handler site again, now you will see “Web App Installed” in the upper right hand corner. To unregister BobPay, scroll down the page and click “Uninstall BobPay Web Payment App.” You can also manually register the payment handler from this page.

For skip-the-sheet:

These features are not yet available in other browsers. We welcome your feedback, especially whether you think these (or similar) features are compelling and other browsers should behave similarly.

5 Responses to Further Streamlining the Payment Request User Experience

  1. Nice features Google team!
    Question: if merchant declares they support both BobPay and AlicePay, but browser doesn’t support AlicePay (or can’t install it just-in-time), then would Chrome offer the skip-the-sheet experience?

    • Thank you!
      As currently implemented, Chrome will offer the skip-the-sheet only if the merchant declares they support a single URL-based payment method. However, from a product perspective, the only thing that should matter is the number of installed (or available for just-in-time install) payment apps. So I will be fixing that in https://crbug.com/877284.

  2. Nice features I expect to be standardized in all browsers.
    Good job.

  3. Pingback: TPAC 2018 Recap | Web Payments Working Group

  4. Pingback: April 2019 Face-to-Face Meeting Recap | Web Payments Working Group