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

> @nickjshearer, do you think we should be using the same response type (with lots of optional attributes) or a different type? We could certainly define a variety of types in the spec or write multiple specs (there doesn't have to be only one). Just looking for your view of the pros and cons.

I do think the same response type should be used. After thinking about this, I don't think they would have to be optional in terms of the JS response, it could simply be noted that those properties may be empty. That is, cardholder name and expiry are required properties, but they may contain empty strings. I'm not sure if that's necessarily better than being explicit in the data model that they're optional fields, but it's another approach.

> The nature of UnionPay leads me to suggest that whilst it is important, I don't believe it qualifies as ubiquitous.

@mattsaxon - I do understand it has its challenges, but in terms of transaction volume and cards issued it outranks all the other card networks...the basic card flow should account for the primary card used in China. Like I said, I'm happy to leave it as-is for FPWD and revise it in the future, as long as we take care of it at some point.

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