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

Hi all,
I'm working on developer resources to tell how a merchant can provide best possible payment UX.
Let me explain my hypothetical best practice - "branded button" approach:

Given gaps between maturity of Payment Request API implementation status between browsers and payment app availabilities between platforms, we must say providing multiple payment method through single checkout button is almost impossible.

![screen shot 2018-09-12 at 13 11 34](https://user-images.githubusercontent.com/218144/45401830-7686f480-b68d-11e8-84ae-696f350ef21a.png)

So the approach I would recommend is to use branded buttons where it utilizes Payment Request API and aim long term goal of unifying those payment methods into a single generic checkout button.

See [this demo website](https://branded-button.polykart.store/).
It looks very similar to what you might have seen in the past, but a different version using the branded button approach with multiple payment methods.

1. Go to https://bobpay.xyz/ and install Bobpay web payment app at the bottom of the page (This will not be needed in Chrome in the future)
2. Go to https://branded-button.polykart.store
3. Find an item and add to the cart
4. Go to [cart page](https://branded-button.polykart.store/cart) and checkout
5. Try the branded buttons

![screen shot 2018-09-12 at 13 16 45](https://user-images.githubusercontent.com/218144/45401959-252b3500-b68e-11e8-963c-12f32b41a9b4.png)

I haven't completed the demo implementation yet but you should see the idea for some extent. The points are:
- You can accommodate payment methods both of ones that supports Payment Request API and ones that doesn't.
- By specifying single payment method in `PaymentRequest`, you can directly launch the payment app skipping Payment Request UI (at least in Chrome).
- By using payment method specific library, you can implement a fallback solution even PR is not available. Google Pay for example (Ideally all Payment Handler developers should implement that).

There are payment method specific best practices as well:
- **basic-card**: As mentioned earlier, Chrome will stop serving cards saved to Google through basic-card starting Chrome 70. But some users do store cards locally, non Chrome browsers have different mechanism to serve basic-cards. Hence merchants can take still advantage of basic-card. Use `canMakePayment()` to determine if you should use Payment Request API (I'm expecting this is where we can use our upcoming visual identity can be used) or a HTML form as a fallback. (note that Chrome still serves cards saved to Google through forms).
- **Apple Pay**: Apple Pay only works on Safari. Use the trick introduced above to determine if a merchant should show an Apple Pay button.
```
if (window.ApplePaySession && ApplePaySession.canMakePayments())
  // Show Apple Pay button.
```
- **Google Pay**: Google Pay uses native app or Payment Handler API where available, pop up window as a fallback. Use [pay.js](https://developers.google.com/pay/api/web/guides/tutorial) library to implement its branded button.
- **Samsung Pay**: Sorry, I need to do a research on this one.
- **Upcoming Payment Handler based payment methods**: As mentioned above, Payment Request can skip its UI if single payment method is specified. Ideally, the payment app provider should implement a fallback mechanism in their JavaScript SDK so that it works similar way as Google Pay.

In summary, it's critical for us to have all browsers implement both Payment Request API and Payment Handler API, in order to get this "single generic checkout button" idea to start rolling. But as a short term workaround, branded approach seems reasonable to me.

It's been a long due, but I'm working on an article summarizing the stuff described above. Let me know your thoughts and ideas.

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