Re: [w3c/webpayments-method-identifiers] Why URLs? (#9)

Thanks for bringing this up again. We're looking at this spec again right now, so it's the ideal time to have the discussion. 

I agree that there are numerous downsides to URLs. We went through all of the various possibilities before settling on them as the mechanism for identifying payment methods.

It probably is worth reading the [proposal](https://github.com/w3c/webpayments/blob/gh-pages/proposals/zach-pmi.md) we're currently considering. When we think about payment methods and how we identify them, we lump them into two categories: "open" and "proprietary".

Open payment methods are ones that can be standardized by the W3C, and for those we are relying on URNs, so many of the issues outlined above by Tab go away for these types of methods. The WG will most likely contain a registry of these different payment methods (e.g. urn::w3c-payments::basic-card).

The second type, however, are proprietary payment systems. These are oftentimes closed-loop systems where only a single player can return back valid credentials (e.g. PayPal, Visa Checkout, etc). For these players, we rely on URLs. There are a few reasons for that:

* There are many different proprietary payment methods out there, and it's not reasonable to ask those payment method providers to have to go through some W3C process (even if we make it light weight) to get an identifier into our registry that makes their method available inside of PaymentRequest. The more difficult we make this, the fewer payment apps we see on the market. The fewer payment apps available, the less adoption we see of PaymentRequest. To put this another way, payment method innovation should not be limited by W3C processes. 
* URLs allow us to make assertions about identity and ownership. If I say I support "https://bobpay.xyz", there's no ambiguity about ownership of that payment method. It also allows us to link method identifiers with apps installed on a user's device. So if user has BobPay installed on the device, we can open up the BobPay application instead of using a website. There are already systems in place to make this assertion. This also affects things like Risk and Assurance in the world of interchange.
* Something can (and should) live at the end of the that URL (e.g. a manifest file) containing information about that payment method. That information can be updated over time if things change. It also allows for additional assertions to be made (e.g. In addition to BobPay.xyz being able to return back BobPay.xyz credentials, we also authorize AlicePay.xyz to return back valid BobPay.xyz credentials). This is another critical use case in the world of payments. But by default, unless this assertion exists, no one else can claim to return back BobPay.xyz credentials.
* When something lives at the URL, it also allows us to kill the proverbial birds with a single stone. From a UX perspective, if the users doesn't yet have a payment app installed but would like to use it (e.g. PayPal.com), the user can choose PayPal from a list and we can fetch information on-demand about PayPal if it's a URL. But more importantly, there are numerous financial agreements that *require* certain payment methods to be listed irrespective of a user's preference. So quite literally these payment methods pay money to the merchant to list their method. This means we have to have a system that allows users to pay with those options even if they don't have them installed if we want the merchant to be able to fully use PaymentRequest.

Given the above, URLs seemed to be the best path forward (even if I agree with all your points). There are just certain use cases that seem to necessitate the use of URLs. That said, if you think we can meet those needs without that, great! More than happy to revise my proposal for an alternate method.

Also, FWIW, I don't agree with this assessment:

>  ...but are not defining what should be at the end of those URLs, if anything, and we're punting that decision to "the markets".

Up to this point, I have not been terribly active in the payments app world (though that should change this week), as I'm focused on getting PR out the door. But I do not see any value in leaving this to the markets. We can and should define what lives at the end of these identifiers and make it a part of the process. If we don't, then I agree that URLs as identifiers become less valuable.

-- 
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/9#issuecomment-239817946