Re: [w3c/payment-handler] Basic-credit security issue (#379)

> For now the most important that it is not possible to have Google Pay, Samsung Pay and Apple Pay in the same time in Payment Request. 

This is a valid feature request in general.

If we're talking about particulars of Google Pay, Samsung Pay, and Apple Pay, however, then their support matrix makes supporting all of them easier. Here's a quick sketch:

|    | Chrome on Samsung phone | Samsung Internet browser on Samsung phone | Chrome on non-Samsung Android phone | Chrome on iOS phone | Chrome desktop | Safari |
|-----|------------------|-----------------------|------------|------------------|---------------|--------|
| GPay | **Android app works if manually installed** | Not integrated | **Android app works and is sometimes pre-installed** | Works through `pay.js` script and popups, not PaymentRequest | **Works through service worker payment handler and PaymentRequest** | Works through `pay.js` script and popups, not PaymentRequest |
| Samsung Pay | **Android app works** | **Android app works** | **Android app works if pre-installed** | Not supported | Not supported | Not supported |
| Apple Pay | Not supported | Not supported | Not supported | Not supported | Not supported | **Built-in and works with PaymentRequest** |

If you use exclusively `PaymentRequest` API and include all three supported payment methods in you request, then you would presented with a choice of apps only in the first two columns (**Chrome on Samsung phone** and **Chrome on non-Samsung Android phone**), only if the user has pre-installed the extra app. In the rest of the cases, the user is likely to not see any app chooser. Instead, the user will launch the available payment app directly.

Does that help to understand today's landscape a little better?

-- 
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-handler/issues/379#issuecomment-740784309