Re: [browser-payment-api] Different card schemes have different mandatory field requirements (#9)

To add some detail here, UnionPay credit cards do conform to the 'usual', ie. BasicCardResponse, it's the UnionPay debit cards that don't have name and expiry. However what concerns me with modelling is that this level of specification is volatile as we have seen from the Meastro investigations.

These discussions raise a few questions for me;

1. Do we need a list of specific card types that we are going to support as part of our 'ubiquitous methods' (note, I've added these in a PR 25, and they don't include UnionPay because of the issue Nick highlights)?
2. Should we really be defining the standard for these card types at all, or should we be getting the card schemes more involved? (I realise this question has been posed a few times, but we've never got down to some real examples of why this is needed before)
3. Could separating the idea of Payment Method Identifier from 'Brand' assist us here to move forward? This might help address the example that UnionPay credit cards can be accepted on the Discover network.

I still propose we accept my PR as it standard as it is more explicit about the problem as it has a fixed list of brands rather than an empty list and therefore calls out the absence of UnionPay from this model.

This does not imply this is the version that will go to FPWD as we may have some more time to consider this further prior.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/9#issuecomment-195719845