Re: [browser-payment-api] Suggest two alternative payment method identifier proposals (#34)

@adrianba,

I acknowledge the cost, but people make a business decision to host useful resources.

Here is my thinking in a nutshell:

 * We need identifiers.
 * We also need documentation of the shape of payment request and payment response data for
   different payment methods.
 * People who are using the identifiers need that documentation to use the payment method.
 * Therefore, the identifiers should be (good practice) URIs to documentation on how to use
   the payment method associated with the identifier.

Otherwise, people will have to hunt around for the payment method specs.

If one has multiple identifiers that are specified by the same payment method spec, 
then those can all (HTTP) redirect to that spec. 

@adrianba makes an interesting point about synonyms. My first reaction is that the payment identifier spec should not define synonym semantics. (I prefer simpler equivalence semantics there, as Adrian has proposed) Adrian mentions a "synonym" functionality at registration time, which I had not thought of. If we push that computation to the payment app, there may still be a way to increase interop among payment apps by encouraging people to define synonyms in payment method specs. I _can_
see the value of having a machine-readable version of synonyms consumable by payment apps.

Ian

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/34#issuecomment-195486990