In general, -0.75 for any sort of grouping semantics in version 1 (we can add this later in v2).
The exception to the above is if we can get a fairly comprehensive list of all payment methods we're going to support in v1 (which I think would be very difficult). If we're going to support grouping semantics, we're going to have to either ask the card brands to manage that, or we're going to have to manage it ourselves. Neither one seems like a good use of this WGs time. Instead, we should push this complexity out to implementations. I'd rather that implementations have convenience methods to generate lists for supported payment methods. For example, having a convenience function (NOT in the spec, but in software implementations) that does something like this:
```javascript
var acceptedPaymentMethods = paymentlib
.generateMethods('visa').except('https://example.com/pmis/esoteric-card').list();
```
-0.5 to card exclusion lists (as it makes the matching logic harder more complex)... unless it's provided by an external library.
In short, we should punt on grouping - let helper libraries define the behavior and we can pull those features in after we get some field use for v1.
---
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-221896822
Received on Thursday, 26 May 2016 15:02:08 UTC