Re: [w3c/payment-request] To address branded button issues and improve privacy, add browser support for payment method selection before the sheet (#777)

In the spirit of getting the ball rolling, I'll drop some ideas that come off the top of my head. These mostly concentrate on allowing the merchant to decide what's the best way to present buttons, all the while trying to protect the buyer's privacy.

### Idea 1

Could we envision a world where `PaymentRequest` gives us back the list of accepted payment methods? (i.e. a more granular `canMakePayment()`) This new call would still be rate-limited.

Say: `paymentRequest.availablePaymentMethods(): string[]` (a list of payment method identifiers)

Accompagnied to this, each payment handler can be queried for their button asset say: `registration.paymentManager.instruments.get("payment-method-id").buttonImage`

### Idea 2

Could we envision a high level abstraction that enables a merchant to build a tuple of branded button and PaymentRequest, without leaking to the merchant what payment method is being presented to the buyer.

For example:

```
interface PaymentMethod {
 paymentButton: PaymentButton;
 paymentRequest: ScopedPaymentRequest;
}

buildPaymentMethods([
 { supportedMethods: "basic-card" },
 { supportedMethods: "samsung-pay" },
 { supportedMethods: "google-pay" },
] as PaymentMethodData[]): PaymentMethod[]
```

A `ScopedPaymentRequest` would be a `PaymentRequest` without the ability to specify `methodData[]`. Every `ScopedPaymentRequest` would only ever have a single payment method.

A `PaymentButton` would be the browser control container containing the payment method brand.

`buildPaymentMethods` would only ever return the `PaymentMethod`s that respond positively to `canMakePayment()`.

In all cases, the merchant would never be able to query any object to determine what is being presented to the buyer.

-- 
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/777#issuecomment-423643505

Received on Friday, 21 September 2018 19:16:27 UTC