Payment Handler Security

A payment handler is user software to make a payment. Payment handlers may be implemented as Web pages, native mobile apps, or even built into the browser. Since the launch of the Web Payments Working Group, we have had as a goal to add extensibility hooks to browsers to foster payment handler innovation.

Chrome is the first browser to ship support for Payment Handler API, which enables users to pay with Web-based payment handlers. These are Web pages that offer services in the context of a payment request (rather than from a link, redirect, or other script). We anticipate that these payment handlers will authenticate the user, enable the user to select an account to pay, and offer value-added services. By shipping support, Google has enabled companies such as Barclays, Capital One, Coil, Credit Suisse, Facebook, Google, Klarna, Lyra Networks, Shopify, Worldline, and Worldpay to experiment with a growing variety of payment methods and user experiences.

The Chrome implementation has also prompted questions how powerful payment handlers should be. We discussed security considerations during recent face-to-face meeting. Rouslan Solomakhin (Google) has compiled a list of choices for a browser team to consider as part of enhancing Web-based payment handler security. I share them below with his permission. I hope these notes prove useful to other implementers of the Payment Handler API.

I’ve organized the implementation notes into three groups:

• When the browser should not show a risky payment handler to the user at all.
• When and how the browser should show a payment handler but limit its capabilities.
• Additional controls to enable users to manage payment handler security.

Do not show the payment handler

Chrome does not show the user a payment handler in these situations:

• The payment handler is identified by an HTTP URL (instead of an HTTPS URL). The exception is for localhost, which is important for development.
• Communication with the payment handler via SSL would involve a red or gray security state listed in badssl.com.
• The payment handler origin is labeled “unsafe” in the Safe Browsing database.

Show the payment handler but limit functionality

Chrome limits payment handler functionality as follows:

• Runs the payment handler in a sandboxed process (and not the main browser process).
• Blocks content included via HTTP; payment handler distributors should include content via HTTPS.
• Blocks cross-origin scripts.

Additional user controls

Chrome gives users additional control as follows:

• Clearly present the origin of the payment handler to the user.
• Provides settings to control payment handler behavior, such as:
  • Do not register payment handlers from a given origin.
  • For a given origin, do not skip the sheet before launching the payment handler.
  • Do not ever skip the sheet before launching the payment handler.
  • Do not allow just-in-time registration or a given origin.
  • Do not ever allow just-in-time registration.

For more information about just-in-time registration and skipping the sheet, see the previous blog post on further streamlining the Payment Request user experience.

More ideas

The Chrome implementation continues to evolve through discussion and feedback from payment handler experiments. For example, Chrome may disable all features by default in the feature policy for a payment handler.

We hope that you will experiment with payment handlers and share your ideas with the Web Payments Working Group. If you spot bugs in the specification, please let us know on our issues list.