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

@zkoch,

>If a merchant says, "I accept card type X", the assumption should always be (for clarity sake) that they support all subtypes of X.

I understand completely a world where there is no grouping (and thus no subtypes). There are only atomic payment method identifiers. That world is verbose but easy to understand.

I want to avoid the need to define (and maintain) groupings. So when you say "they support all subtypes of X" that assumes that someone has defined a grouping somewhere and people have to know where and it has to be maintained, etc.

"Not supported" functionality does not require any grouping definitions. It is an extension of the "no subtypes" world where all computations can be done merely with two lists of identifiers ("supported" and "not supported") and no other information.

> 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.

Matt referred me to this long list of subtypes:
 https://www.bindb.com/bin-list.html

One use case he referred to was a merchant not supporting a particular subtype due to terms and conditions.

>...the complexity of a "not supported" addition to the API?

I have not yet spent time thinking about or discussing the cost and complexity of this approach. That's an important activity. 

Ian




---
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-203101019