Re: [w3c/payment-request] Some clarifications with Payment Request API (#774)

Hi @adimallikarjunareddy, as you point out, the reality of the world today doesn't match all of the long-term goals of Payment Request. There are lots of minor details about the state of different browser implementations, the rules of individual payment methods, etc., which make it _currently_ impossible to ignore the details and just use one Payment Request integration everywhere. But, the groups is making progress on some of these issues and there are already many cases where using Payment Request (where available, subject to rules, etc.) is a better and higher-conversion experience than most online checkout pages.

Let me reply to your four challenges and then at the bottom offer some summary advice:

> 1. Apple Pay API and branding rules

There are two versions of the Apple Pay API, an older one that is not Payment Request based and a newer one that is Payment Request-based but does not have quite all of the same features. Apple Pay only ever works in Safari, and no other payment methods are available via Payment Request in Safari. (This may change in the future, but I don't believe Safari has any public plans to add other payment methods.) Apple's guidelines require you to use the official Apple Pay button even when using Payment Request. But this isn't much of a problem since Apple Pay is the only method that works via Payment Request in Safari anyways.

> 2. Payment Request on Chrome + Google Pay

Chrome's Payment Request implementation supports basic-card and custom url payment methods, of which Google Pay is one option. The basic-card method also works in some other browsers (including MS Edge).

As you mention, Google has a pay.js library which will let you access Google Pay cards from other browsers, though it doesn't always use the Payment Request API (because of browser support) and prevents you from also requesting other types of payment methods through the same button.

> 3. Various kinds of cards in Google Pay/Chrome

The two types of cards correspond to "card on file" cards, where Google just has the raw card number (the same cards that are used as autofill options, saved from previous checkouts) and device-tokenized (fka Android Pay-style) cards, where Google has actually required the user to authenticate themselves with their bank to prove they are the cardholder. Which of these types is available at one time depends on how the user is logged in to Chrome and Google properties and what device they're on. Having done some work with Google Pay for Stripe, there are good reasons for this to be the way it is, and really as a merchant you shouldn't have to worry about it.

> 4. Stripe's Apple Pay / Payment Request button

Because Safari only supports Apple Pay, and Apple Pay is only supported in Safari, right now Stripe provides this integration option that will show the Apple Pay button in Safari and a generic Payment Request button in other browsers that support it. The Stripe.js code handles all the browser detection and meeting the Apple branding guidelines so that you don't have to worry about it. But you could implement the same strategy yourself without Stripe's library if you wanted to.

### What is a merchant to do?

The situation today is complicated, no mistake! It definitely isn't as smooth and wonderful as the ideal future of a single Payment Request button would be. 

A few personal thoughts (this is wearing my "works on payment request" hat, rather than my "employee of Stripe" hat):

- Because of browser support not being universal, most merchants should continue to provide a regular checkout form where customers can type in their credit card details. 
- That said, in browsers that support it, Apple Pay/Payment Request is a good experience and can lead to strong conversion rates. I'd suggest making it a clear alternative to your regular checkout form where available.
- How you integrate Payment Request currently depends a lot on your PCI compliance. If you do extra PCI compliance work and are allowed to handle raw card numbers directly on your website, you can do a direct Payment Request integration in lots of ways. (Some options below.) If you do not want to be subject to extra PCI burden, you will probably want to use a third-party library provided by your PSP (Stripe has one) or Google's pay.js, which can perform parts of payment request for you so your code never handles raw card numbers. You can also look forward to standardization and adoption of the tokenized-card payment method, which will allow you to receive network tokens for cards, which may not be subject to extra PCI compliance.
- Because of browser-specific capabilities restrictions and payment method-specific rules, you should not expect to have a single universal Payment Request button UI. In Safari, you'll want to use the Apple Pay button. In Chrome, you might want a generic Payment Request button because it can support many payment methods, or you might want a branded "Google Pay" button because customers are more likely to understand what it means. (There is also work underway to have a standard visual identity for Payment Request, which may eventually lead to a button that customers recognize.) In other browsers, you _may_ want to use Google's pay.js to get a "Google Pay" button that behaves similarly to Payment Request. A lot of these details depend on the audience of customers, devices, and browsers that you have and unfortunately there aren't enough case studies available to prove which strategy is best.

(Putting on my stripe hat)
For merchants who are already using Stripe or considering it, I would recommend considering using our magic Payment Request integration. That handles the Apple Pay v. Payment Request UI details for you, and as time goes on, we'll add new payment methods and browser support as they become available so that your checkout form gets more powerful over time and you don't have to worry about the details.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/774#issuecomment-420401687