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

Your response is consistent with how I understood the functionality of Stripe.js through this [demo](https://stripe-payments-demo.appspot.com/). 

> 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 API call everywhere. But, the group is making progress on some of these issues and there are already many cases where using Payment Request in a smart way (where available, subject to rules, etc.) can provide a better and higher-conversion experience than most online checkout pages.

I completely agree with the fact that this will improve the conversion rate and is one of the reasons why we implement for merchants :)
 
> 
> Let me reply to your four challenges and then at the bottom offer some summary thoughts on what merchants should think about:
> 
> > 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-based API. But this isn't much of a problem since Apple Pay is the only method that works via Payment Request in Safari anyways.
> 
> > 1. 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.
> 
> > 1. Various kinds of cards in Google Pay/Chrome
> 
> Rouslan answered this better than I can above.
> 
> > 1. 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.

Yeah I liked this idea of implementation. 💯 

> 
> ### 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. You may want to do a generic Payment Request button and use feature detection so that it shows up only when that browser starts supporting 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.
> 

Looks like this is the only way to achieve more coverage of all payment methods across different browsers.

> (Putting on my Stripe hat)
> 
> * For merchants who are already using or evaluating Stripe, consider using our [✨magic✨ Payment Request button](https://stripe.com/docs/stripe-js/elements/payment-request-button). It 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.
> * Even if you don't use Stripe, the bottom two checkout form examples on our [Elements Examples page](https://stripe.github.io/elements-examples/) show ways to integrate a regular card input form with an Apple Pay/Payment Request button in a fairly non-intrusive way so that customers can use whichever one they prefer.

In general, even our implementation strategy is similar to what you have explained. We already offer regular checkout that collects credit card information (PCI complaint) and provides other buttons to accelerate checkout for better conversion.




-- 
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-420413987