Re: [w3c/browser-payment-api] What semantics is needed for payment method specific data? (#143)

Can I confirm this issue pertains specifically to the “object data” parameter of Payment MethodData

I’m in favour of Ian’s option 2

Here would be an example structure for this to represent the example I was giving for specification of required fields (as per PR #114, which I have closed pending this debate)

      “VISA”: {
  requiredFields: [“cardSecurityCode”, “billingAddress”]
 }

 “Mastercard”: {
  requiredFields: [“cardSecurityCode”, “billingAddress”]
 }


Now, since VISA and Mastercard are very similar (sharing a common field structure as defined in the Basic Card Payment Spec) , it seem to be that it should be possible to form some sort of standardisation here, either by putting the required fields at the top level;


 requiredFields: [“cardSecurityCode”, “billingAddress”]
 

This is not idea as it would apply to other, non-card methods and lead to unexpected behaviour, so this is really a suggestion that we might need some sort of grouping analogous to BasicCardResponse


 “BasicCardRequest”: {
  requiredFields: [“cardSecurityCode”, “billingAddress”]
 }
 

We may however find that some fields do indeed apply in a wider scope, e.g. email address, name etc., so here might be an example;


 requiredFields: [“emailAddress”, “payeeName”],

 “BasicCardRequest”: {
  requiredFields: [“cardSecurityCode”, “billingAddress”]
 }
 

In terms of schemas/WebIDL, we might define the fields at the route to be a base schema with extensions for the embedded object. So BasicCardRequest in this example might inherit from the definition of BaseRequest such that the definition of requiredFields and other items might be reused.

This relates to issue #146

---
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/143#issuecomment-215738721