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

I agree with @zkoch that with basic card there is at least a chance of success and with a truly proprietary payment method that is not the case BUT I think @adamroach 's point is valid; if a payment app wants to insert itself in the user's checkout flow they will do so irrespective of how likely it is that they will take a user down a path to success.

Let's assume I am a payment app publisher with my own proprietary payment method I want to promote and I'm not going to be restrained by ethical considerations:

I need to go out and get data on which merchants support which payment methods so I can assess my competition and I need to get my app installed as widely as possible. The easiest way to do this is to say I support as many payment methods as possible and invest my energy in getting users to install my payment app through promotions, incentives, etc. (The malware playbook)

Supporting basic card is easy and it's likely I will always be able to persuade a user to enter a card number once my app is invoked so if the user invoked my app thinking they'd be paying via some proprietary method I can simply say "Sorry, there was an issue using bobpay.com, but you can pay via card by simply entering your card details below".

By this time I have the origin of the merchant (probably see https://github.com/w3c/webpayments-payment-apps-api/issues/27) and the list of ALL the methods they support (all sent to me because I claimed support for all of them). If I can use my cunning (I'm a malware distributor so I have lots) to coax the user into completing the payment anyway then nobody is the wiser that I am simply farming data.

So, while I see the value in trying to manage which apps support proprietary payment methods I'd say that the risk you have highlighted is actually greater with generic methods like basic card because it gives me the ability to easily conceal the fact that I am a malicious app (by actually completing the payment).

This is all ignoring the fact that I could be farming these card numbers too...

I don't think we should be solving this problem during checkout, we should be solving this during registration.

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