Re: [w3c/webpayments-method-identifiers] Resolve whether browsers need to police payment app claims of supported methods (#11)

@adamroach It's not that I don't see the theoretical list of possibilities. I'm more interested in real-world examples, as those are the problems I'm interested in prioritizing at this point and what should inform our design. 

As it turns out, in practice what we see are:

* Lots (and lots) of examples of basic card
* (1-2 examples of PayMe)
* Many examples of Wallybux

ABC-Co and Altavista card tokens are challenging to map to, as I'm not sure exactly what they could be. They could be gateway tokens (e.g. Stripe) or they could be network tokens (e.g. Visa). As of right now, Gateway tokens happen out-of-band (they're an integration question) and network tokens lack any kind of standardization.

Also, I think the proposals I've outlined still support all of these use cases, but the by-default design maps to the most common scenarios (basic card and Wallybux).

But that doesn't mean we can't provide a mechanism in the manifest, for example, to say, "I'm completely open, anyone can use me" or "I'm completely open but only if we have an existing relationship."

-- 
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-method-identifiers/issues/11#issuecomment-240770131