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

It may be useful for anyone new to this work to read both:
1. [This overview](https://w3c.github.io/webpayments-overview/) and
2. [This early architecture proposal](https://github.com/w3c/webpayments/wiki/A-Payments-Initiation-Architecture-for-the-Web) which is now somewhat outdated but provides useful context to some of the design considerations.

What these APIs are attempting to facilitate is a conversation between a merchant  (website) and user that looks something like this:

* User: I want to checkout  _(click checkout button)_
* Merchant: The total is $10 and you can pay by card, Bitcoin or Paypal _(website calls PaymentRequest API, browser prompts user with choice of **payment apps** that support one or more of the **payment methods** the merchant accepts)_
* User: I will pay via my ABC Bitcoin Wallet. _(User selects a Payment App that supports the Bitcoin payment method, browser invokes ABC Bitcoin Wallet and user interacts with wallet to authorize payment, wallet return response to browser which passes this back to the website)_

This may seem like indirection via the browser (the mediator) but it is necessary for protection of the user's privacy. 

In terms of "what is a payment app"; it could be many things. It could be a piece of Javascript that runs (ServiceWorker-like) in a non-UI context but it may also be a mobile app installed from the app store. Also bare in mind that the group is attempting to solve for use cases where there is no browser or even user interaction (example: a parking meter prompts a vehicle to pay for it's parking by passing it the URL for a payment request - see the [HTTP API](http://w3c.github.io/webpayments-http-api/) for some thoughts on this) and the ability to identify payment methods will benefit from the name-spacing and context gained by using URIs. (I am also aware that not everyone in the group considers this an important design goal but that doesn't mean we should ignore it, put differently the browser APIs are not being designed in a vacuum)

Note also that at W3C we can only define how a browser might invoke a payment app via web technology (where @adamroach 's proposal is the latest thinking in this regard) but nothing prevents browsers from offering an integration via browser extensions or some other platform specific mechanism (example: an app installed from the app store calls a platform API that makes all installed browsers aware of the payment methods it supports), especially for invoking "native" apps. Therefor we're limiting our scope to invocation via @adamroach 's proposal but we need to consider if the use case of a "native" app, registered via the browser APIs is still important.

So, the payment method identifier is exactly as @adamroach describes, purely an identifier. In fact, user's will likely never need to understand the concept of payment methods. They will be prompted through a variety of channels to install payment apps (in many forms) and these apps will support one or more payment methods.

When the user needs to make a payment they will be prompted with a choice of payment apps (not methods). The intersection of methods accepted by the merchant and supported by the users many apps is used by the browser to decide what choices to offer the user.

The complication in this is @zkoch 's assertion that there will be payment methods that are proprietary and for which there is a limited set (likely 1) of apps that will support this method.

I believe the problem here is that we are conflating identifying the **payment method** with identifying the **payment app** to try and solve for concerns around bootstrapping the ecosystem.

The scenario is this:
* A user visits a merchant that says they accept PayPal (as an example)
* The PayPal payment method is only supported by the PayPal payment app
* If the only information provided by the merchant to the browser is "urn:payment"paypal" then the browser has no way to assist the user in getting the right app for this payment method whereas if the identifier was "https://paypal.com/app/v1" and that URL pointed to some kind of manifest then the browser could fetch that and use the information in that manifest to prompt the user to install the Paypal app before continuing with their checkout.

What I am hearing from @zkoch is a proposal to use URLs when the browser is expected to fetch and process (i.e. it will be machine readable) the resource at the end of this URL AND for the format of this resource to be well defined by this group.

There is a counter-proposal from @ianbjacobs for the payment request to allow the merchant to provide "recommended apps" for any of the methods they support and thereby provide the browser with additional information about the apps that are available that support a specific payment method directly in the payment request.

I believe that the editors of the Payment Request API spec don't like @ianbjacobs proposal because, up to now, they have been able to to avoid any mention of payment apps in that specification and kept the two very loosely coupled. Adding "recommended payment apps" to the payment request API would change that.

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