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

> That's why I implied that the browser might detect this situation when it happens, and lead the user down a path that makes it clear that uninstalling the app is probably the right course of action.

We've been detecting and trying to prompt users to remove unwanted software for a long time. It is not easy and it is very confusing for users. You're much better off trying to prevent the problem up front (as best you can).

> Sure, but if it's a bad experience for proprietary apps, then it will be a bad experience for standardized apps.

Not in the same way (assuming you mean payment method instead of app). Because any payment method that is standardized means that it's open. Which means there is at least a *path* to success.  As an example, let's say that a merchant supports basic_card payments for Visa and Mastercard, but in my AliceWallet I only have an American Express card. That's a failure scenario, but it's not crazy to imagine AliceWallet putting me through a flow where I could add a Visa or Mastercard. This could also hold true for other open payment methods (credit transfer, ACH, etc). It might not be ideal, but it's not irreparably broken.

But in the case where PaymentRequest is called with, say, only a single supported method, "bobpay.xyz", which is a proprietary payment scheme that no one else can support, there is no world in which my ending up in AliceWallet leads to success. It is impossible. It is a failure scenario which can and should be avoided.

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