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

> Every payment processor has relationships with their merchants that allow those merchants to accept payments using the payment method defined by that processor. In the real world this means AliPay, AndroidPay, Apple Pay, PayPal, WorldPay etc.

Yes.

> These processors MAY (and I think we can assume WILL in most cases) define a "proprietary" payment method. (In fact Alipay have already defined the payment method spec for theirs).

I don't necessarily agree with your assumption here. Chase Paymentech has been around since the 80s and hasn't done this. FirstData has been around since the 70s and hasn't done this. Those are the two biggest ones (at least in the US). AliPay hasn't yet opened up their system so that other players can return back AliPay credentials (at least not yet). WeChat Pay, the second largest (and rapidly growing) Payment Method/App is not open and has not published any plans to become open.

All this isn't to say that it can't or won't happen. Just that I don't see much movement in the industry yet around this.

> Therefor it follows that a proprietary payment method will want to have a way to link multiple payment apps from different origins to their payment method.

As I said in #12, I don't think it's being argued that this shouldn't be supported. Just that by default, this isn't common in the industry right now and we should design things accordingly.

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