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

We're going to start splitting hairs, here. For example, Stripe is fundamentally just an ISO of Wells Fargo Merchant services which leverages Chase Paymentech. Braintree is an ISO for a wide variety of players (including both Chase and FirstData). But at their core, they're really just card payments. PayPal is an example of a 1:1 relationship between App and Method.

But I guess what I'm looking for are more real-life examples of what you're proposing. I don't think I'm convinced by the "it doesn't exist because there's no incentive" bit. It's an easy argument to make that oftentimes doesn't hold true.

That said, I think we can support all of our goals here:

* I want to be able to prevent arbitrary payment apps for claiming support for proprietary payment methods. If we can't prevent this, we're going to have a hard time convincing existing players to enter into our ecosytem, which makes adoption by merchants more difficult.

* We both want payment methods that are completely open, somewhat open, and not open at all to be able to play in the ecosystem. There's room for all of them in the marketplace. We can design a system that allows for all of these to co-exist. The market can then decide what is best in the long run.

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