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

Pull request #133 (https://github.com/w3c/browser-payment-api/pull/133) relates to how payment method specific data is passed through the API.

A separate question is: what semantics is needed for this data (however it is supplied)?
We have several options (however the data is passed through the API):

1) Leave it undefined. Payment apps would have to figure out themselves
what the data mean, possibly through other specifications. This would give
merchants maximum flexibility to encode the information however they want,
but we would decrease payment app interoperability.

2) Payment method identifiers are (the only) keys. One example in the FPWD
suggests this is what is intended, but it's not formally defined that way in the spec.

3) We could specify some sort of expression language to increase interop. To illustrate what
I mean (but not what I am proposing), one could imagine this sort of spec (where "PMI" is
short for Payment Method Identifier):
 
   date :: =  ( data key ":" value ) *
   data key ::= <PMI> [, <PMI> ] | "*"

(Apologies for poor BNF)

Which means you could do things like this:
 
  pm1: { .... data here .... }                       /* Basic case */
   * : someValue                                       /* Applies to all payment methods */
   pm1, pm2, pm3 { someFlag: true }      /* One value shared by multiple payment methods */

This could be powerful from a developer perspective (more expressive, more terse) but
complicated for implementers (e.g., custom parsing of multi-PMI data keys). I'm not proposing
this approach because I believe it is overly complex for v1.
  
I believe we should support both of these goals:

 - Support payment method specific data in the API
 - Promote payment app interoperability (meaning: two apps supporting a given payment method
   can follow specifications and behave similarly).

Given how fundamental payment method identifiers are to the architecture (so they
will be widely supported and understood), and without additional experience, I am
personally fine with option 2 above.  But if we choose that option, the spec needs
to include normative language.

Ian

---
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