Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)

This is starting to feel a lot like a duplicate of #34, should we close one of them?

> And I still think many of them are relevant.

The only ones that I would say are relevant to URI's as identifiers we are already discussing and essentially the argument against them boils down to: _"developers are lazy and so on the odd occasion when they will hand-code a payment request we shouldn't make them write out whole URLs"_.

I see a great number of benefits to using a URI since this is what URI's are for, identification and only a very weak argument against.

@ianbjacobs said in #34:

> short strings for common methods, that are listed in the spec. The "formal" spec can list the "approved" ones and the Editor's draft can be updated easily for the "next ones to be approved but aren't yet."

I agree that historically systems that use URIs as identifiers have sometimes faced issues with developer adoption but I'd argue that this is more often the case when the system tries to accommodate lazy developers by making the whole system more complicated with aliases and short-names.

A developer that sees a payment request example as her first exposure to this standard and sees a list of payment methods that is a mix of short-strings and URIs would be understandably confused as to what the payment method identifier is. On the contrary, if these were all URIs and the majority resolved to a resource that helped them understand how to implement the payment method I'd consider that more developer friendly than short-string identifiers for a subset of the payment methods.

Further, a dependency on these URIs resolving to something useful and machine-readable is the shortcoming of many other systems that use URIs as identifiers yet in this system that would not be a hard requirement and the URi would still be useful long after it stopped resolving.

TL;DR: despite URIs being exactly the correct thing to use as identifiers on the Web (that is what they were designed for) there always seems to be resistance within the W3C to use them as such. In this instance the many reasons they have been problematic in the past are also not valid and so I would strongly encourage their use.

---
Reply to this email directly or view it on GitHub:
https://github.com/WICG/paymentrequest/issues/35#issuecomment-163737046