Status: This is a draft document. It may be incorrect and does not represent consensus. Questions? Contact Ian Jacobs <[email protected]>.

The purpose of this FAQ is to help merchants and service providers understand the status of Payment Request API deployment as of the end of 2018, and to provide practical guidance on the use of the API for some payment methods.

Note: Some of the complexity evident below is mitigated for through payment service providers.

See caniuse.com information about Payment Request API.

The primary benefit is a streamlined and faster user experience. Users quickly reuse cards stored in the browser. All major browsers except Safari support it (or soon will).

• For now plan on two checkout flows: (1) Payment Request (2) A fallback form.
• The fallback form is for:
  • Safari users
  • Users of older browsers that don't support Payment Request

Notes:

• Because basic card data is not tokenized or encrypted when it leaves the browsers, merchants and PSPs need to take into account PCI-DSS as they would if they were accepting the same data through a Web form.
• Google provides a shim for additional stability in different browsers. However, you can use the shim OR Payment Request directly, but not both.

• See Apple Pay on the Web

• See Deep Dive into the Payment Request API

• See Simplify payments with the Payment Request API

• See Web Payments Integration Guide

One goal of Payment Request API was to simplify checkout by enabling merchants to provide a single "buy button" that, when activated, would show available payment methods. This is somewhat feasible today and is likely to become more achievable as browser implementations of Payment Request mature.

In the short term, here is some guidance:

• First, note that one can invoke Payment Request from one or more buttons in the same page.
• Apple Pay branding guidelines require a separate button for Apple Pay. That button can be attached to Payment Request API, but the button must stand on its own.
• Other payment methods can be implemented behind a single "buy button", and reached by the user from the sheet that opens when the button is pressed.
• Merchants can mix and match "single payment method" buttons and "multiple payment method" buttons on the same page.

There are two tools available:

• canMakePayment() which provides some information about supported payment methods, but can be rate-limited for privacy reasons.
• Browser detection through User Agent string parsing

NOTE: The Working Group should continue to investigate improvements to this situation.

Today:

• Safari supports Apple Pay.
• Edge supports Basic Card and Microsoft Wallet.
• Samsung Internet Browser supports Basic Card and Samsung Pay and is expected to later support Web-based payment handlers.
• Chrome on Android supports Basic Card, Google Pay, third party native payment handlers, and Web-based payment handlers.
• Chrome on desktop supports Basic Card, Google Pay, and Web-based payment handlers.
• Firefox will soon support Basic Card, and is expected to later support Web-based payment handlers.

That is an ongoing discussion within the Web Payments Working Group and ultimately is a business decision by the companies that make browsers.

Chrome ships today with support for Payment Handler API, which allows Web-based payment handlers to bring more payment methods to the Web. We anticipate support in Firefox and Samsung Internet browser as well.

When used as part of a payment flow, it is reasonable to support the creation of a user account using the data received from the PaymentRequest call. When doing so, be sure to provide sufficient context so the user understands how data will be used. We also recommend consulting payment method documentation for additional usage terms and conditions.

• See the original issue 774 that motivated this FAQ.