Re: [w3c/browser-payment-api] Add canMakeActivePayment() function to PaymentRequest object. (#310)

I also think that `canMakeActivePayment` is kind of a strange name for a method on a PaymentRequest object, as PaymentRequest objects do not make payments. Something like `canUserMakeActivePayment` could mitigate that.

Writing out the algorithm for what the method will do may help in determining its name. It seems to me that it would roughly be:

1. If the user has a payment app installed for one the payment methods in the request, return true.
2. If the one of the payment methods has "built-in" support (e.g. UA may support basic card) and the user has already registered a payment instrument, return true.
3. Return false.

If it's something like the above, I think it's only going to be the case that "active" makes a difference for basic card. For any other method, the mediator can't really determine what payment instruments are available, right? At least if/until something is exposed at the payment app level for the mediator to be able to know that information.

It seems like what's really being asked is: "Has the user ever done anything to enable payments with any  of the specified payment methods (or will they be forced to configure something)?"

Some alternative names may be: `isPaymentMethodAvailable`, `isPaymentMethodConfigured`, `isUserReady`, `requiresSetup`, `requiresConfiguration`.

-- 
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/browser-payment-api/issues/310#issuecomment-261130645