prapi deployment faq

Status: This is a draft document. It may be incorrect and does not represent consensus. Questions? Contact Ian Jacobs <ij@w3.org>.

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.

Which browsers support Payment Request API?

See caniuse.com information about Payment Request API.

What is the benefit of accepting Basic Card?

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).

How do I use Basic Card ALONE with Payment Request?

• 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.

How do I use Apple Pay ALONE with Payment Request?

• See Apple Pay on the Web

How do I use Google Pay ALONE with Payment Request?

• See Deep Dive into the Payment Request API

How do I use Microsoft Pay ALONE with Payment Request?

• See Simplify payments with the Payment Request API

How do I use Samsung Pay ALONE with Payment Request?

• See Web Payments Integration Guide

How do I support multiple payment methods through Payment Request API?

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.

How do I detect browser and payment method support in order to build a checkout experience?

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.

Which browsers support which payment methods?

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.

Will browsers support more payment methods in the future?

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.

Is it OK to use the response from PaymentRequest call to create an account for the user?

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.

Other notes

• See the original issue 774 that motivated this FAQ.