Re: [w3c/webpayments-methods-card] Added BasicCardRequest dictionary supporting specification of RequiredFields (#4)

I had expected the requiredFields to specify "billingAddress" to say if the address was needed or not, I hadn't expected it to be specific about which sub-fields.

Yes I think the implementer could return only the required fields and any mandatory fields. Currently only the PAN is mandatory.

Whilst this would conform to the specification, I believe a sensible implementation is to return as much info as possible from what is already captured. So expiry date is effectively a must for most cards (apart from UnionPay. It's the payment apps domain to know this.

The specific use case for requiredFields in the card space is for CSC, this should not be stored to comply with PCI, so must be captured each time. This can conflict with a frictionless checkout and the merchant may have previously registered the user, hence have other motivations for fraud.

There is a similar requirement for billingAddress.

Regards,
Matt

Sent from my iPhone

> On 18 Jun 2016, at 18:36, Rouslan Solomakhin <notifications@github.com> wrote:
> 
> LGTM to submit as-is. Two follow up questions:
> 
> Once billing address is specced, do billing address field names go into the same required fields list?
> 
> Would it be OK for an implementer to return only required fields?
> 
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 


---
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/webpayments-methods-card/pull/4#issuecomment-227235981