Re: [w3c/browser-payment-api] Detecting payment method support (#247)

The current API is designed to avoid sites probing for what a user supports. Following a pattern used elsewhere, you commit to calling the API but if it turns out the API couldn't satisfy your goals then you revert to your fallback flow. This avoids the need for a `validate` method.

The flow should look something like this:

  1. When the user clicks "Checkout" you instantiate a PaymentRequest passing in all the information about the transaction and the payment methods you support.
  2. You call `show()` and wait for the promise that is returned to settle.
  3. If the browser can't satisfy the payment request, say because the user doesn't have any matching payment apps or instruments, then the promise is rejected with a `NotSupportedError`. When you see this result you redirect the user to the fallback flow.
  4. If the browser can satisfy the request then the payment request continues until either the user cancels or the promise resolves with the payment response.

If a user doesn't currently have the ability to pay using a supported method then the user agent may choose to offer to help the user install or configure that method. For example, if the site accepts `basic-card` but the user doesn't yet have any card details entered then the user agent can prompt the user to add one in order to complete the transaction. Since the next time the user sees such a site they will have a card entered the cost is only incurred infrequently. The normal flow is that the user does indeed have a payment method available to them.

For this reason I don't support adding a `validate` method or similar mechanism.

-- 
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/247#issuecomment-247743058