@adrianhopebailie > Unless I have missed it I don't think anyone opposed to grouping has said why. Can those opposed to grouping provide some reasons why? Sure; that's easy: if the list of potential identifiers that people want to use is manageable (such as the [list Zach proposed](https://lists.w3.org/Archives/Public/public-payments-wg/2016May/0018.html)), adding a grouping mechanism is a fairly complicated task. Simply enumerating supported types is much simpler to specify, much simpler to implement, and much simpler to use. On the other hand, if we're going to allow granularity that in any vague way approaches the size of [the list that Matt pointed to](https://www.bindb.com/bin-list.html) -- where I count 1,427 different identifiers -- then simple enumeration is clearly too cumbersome, and the extra complexity of grouping is warranted. If we're talking about O(10) identifiers, then I don't think the complexity of grouping makes any sense. It's just too much work for not enough payoff. If it's O(100) or O(1000), then that's a very different story. I propose that we need to shelve this question for the moment, and start a conversation about card payment type identifier granularity. After we've reached some kind of conclusion on that, we come back to this issue, and I think will have the information we need to make a sensible decision. Until then, we're just stabbing blindly into darkness. --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/w3c/browser-payment-api/issues/30#issuecomment-221953607
Received on Thursday, 26 May 2016 18:25:19 UTC