Re: [w3c/browser-payment-api] Should we define nesting/grouping semantics for payment method identifier matching? (#30)

While I agree with your set of necessary functionality, I don't think I agree with the proposal that we need a way to explicitly say what payment methods are not supported. If a merchant says, "I accept card type X", the assumption should always be (for clarity sake) that they support all subtypes of X. If they don't, then they shouldn't say they support "X" - they should list exactly what they support. I don't think that's an unnecessary burden to place on merchant (they are doing it currently, after all).

I would be interested in more real-world use cases, though. The most prominent example I can think of is that a merchant supports Visa Debit but not Visa Credit. Are there other examples that you can point to that would merit the complexity of a "not supported" addition to the API?

---
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/30#issuecomment-203095163