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

The content of any payment card is defined by ISO7813 (https://en.wikipedia.org/wiki/ISO/IEC_7813).
eCommerce is effectively a manual capture of what's described in this standard so I think we can define which data is the minimum standard for any payment card but also allow for a bunch of additional data that is useful for non-standard cards.

That said, we need to balance a very flexible format that is very accommodating with a rigid format that potentially forces us to define a new payment method spec for certain cards because they can't be accommodated by the basic spec.

The only benefit of being rigid is that the website can have better defined expectations about what data they will receive. In my opinion, if a website supports UnionPay cards then they expect to do a null value check against certain fields anyway so this value is negligible.

My suggestion is that we define the set of fields that accommodates the most use cases (so at least we standardize on field names) and don't make anything mandatory.

I don't advocate even making the PAN mandatory because we may add an "encrypted_pan" or "tokenised_pan" field which can be used instead of the PAN.

TL;DR: I see no value in mandatory fields. The real value we are getting out of this standard is a set of standardized field names and formats.

---
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/9#issuecomment-199074755