Resolve whether browsers need to police payment app claims of supported methods #11
Comments
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. |
Sure, but if it's a bad experience for proprietary payment methods, then it will be a bad experience for standardized payment methods. If I want my crapware to appear in the list every time someone goes to pay for something, I'll register as supporting every W3C-defined PMI. If you can fix that problem, then you fix the one you're complaining about. If you can't fix that problem, then the entire system is already broken in the way you describe, and irreparably so. |
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).
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. |
|
[Yes, I edited my previous comment to fix "app" -> "method"]
No, now you're describing a different situation. The thing that you're claiming is unacceptably bad is malware putting itself in the list. And, again, if it's unacceptable in one case, it's unacceptable in the others. The fact that we can't police one and can (with additional mechanism) police the other doesn't make the problem more severe for proprietary methods or less so for open ones. I agree with @dlongley's comments here; what you're proposing will draw a bright line between proprietary and open methods. If the problem is as severe as you assert (and I don't accept that premise, but I assume you do), then the result will be that requesting a standardized payment method will become a liability that merchants will avoid. If what you assert is true, and we accept your proposed remedy, then standardized payment methods will be dead on arrival. |
|
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 w3c/payment-handler#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. |
|
@zkoch had mentioned that he wanted some notion of what kind of real-world relationships we might see between payment methods and eligible apps. Off the top of my head, I can easily foresee the following kinds of payment methods existing in the ecosystem, and I think we want to ensure that we can support all of them:
|
|
@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:
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." |
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. 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). We should assume that these processors will also want to allow their merchants to publish payment apps that can process payment using these and other payment methods. 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. |
Yes.
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.
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. |
Because right now there is no incentive for a merchant to publish a payment app |
Those are bad examples. They process card payments. We're looking at eWallet systems (for want of a better word) like Paypal, Stripe, Braintree who allow their payments systems to be embedded in other apps already today. |
|
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:
|
Not sure this is relevant. The people that will write payment apps and publish new payment methods are the ISOs that deal directly with the merchants and users. Using PayPal as an example, are you suggesting PayPal would not want Shopify to offer PayPal as a payment method if Shopify had a payment app that was used by all of their merchants?
That's not what I am saying. I am saying it doesn't exist because there is no such thing as a payment app (incentive was perhaps the wrong word) today. The closest thing we have to a merchant published payment app today is their own checkout page where it is definitely possible to pay via "proprietary" methods. |
|
I can understand if this statement (emphasis mine) is more than just conjecture, but I would find it a little surprising. Is it more than conjecture?:
Anyone can claim whatever they want, but I gather that you're talking about that claim translating into the app actually showing up as a choice. But it seems like the only time this extra protection would have an effect would be when no open methods are offered by the merchant, right? Isn't it more likely that merchants will offer at least one open way (e.g. basic card) to pay? Certainly many will. If a merchant offers, for example, both PayPal and basic card, then any protection mechanism implemented for proprietary methods will be ineffective, as options will appear for both mechanisms, including any bogus options from disreputable apps. If the user has indicated that they only want to use a particular app for PayPal and they've indicated a preference for PayPal over basic card, then I would expect that the choice screen could be skipped; but this approach works for both open and proprietary methods. |
|
Closing this issue with the answer "yes". This is being handled via manifest files. For proprietary payment methods, the expectation is that origin and digital signature information in the payment method manifest will provide browsers with information to do checks. See: The payment apps task force is also discussing payment app manifests, and so discussion has moved there about the contents of those files. |
There's a conversation among @zkoch, @dlongley, and me starting with this comment: #9 (comment) -- I'm moving it to its own issue because it's not strictly relevant to issue 9.
The crux of the matter is: is it necessary to have some technical countermeasures to prevent malicious apps from registering with a claim of supporting payment methods that they cannot actually fulfill? If so, is there a different need for W3C-defined payment methods versus third-party-defined payment methods?
The text was updated successfully, but these errors were encountered: