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

@tabatkins 
> Ah, I see. It looks like y'all are indirecting thru the "request_url" - an app somehow informs the OS that it will POST payment information to a particular url, and then a website comes along and says "hey, the app that can post to this `request_url` should be associated with this `payment_app_id`", and then another website comes along and says "hey, boot up the app that's been connected to this payment_app_id, then hand it this payment request info and let me know when it's finished".

No, you've got both the ordinality wrong and the thing that the website asks for wrong.

The website says "boot up one of the potentially _many_ apps that are associated with this `payment_method_id` (not `payment_app_id`)" -- and then the browser gives the user an opportunity to select from among the many apps that can handle `payment_method_id`.

As a minor detail that doesn't really change _this_ conversation, the `POST` thing is going away. The actual app API is (if people generally agree with the proposal) likely to look [something like this](https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/jsapi.md)

> Unless the webpage is registering a SW as a payment method, of course, rather than an app providing that functionality...

I think you're running into a terminology impedance mismatch. In the vocabulary defined by the web payments documents, "payment app" would include a thing that's basically a service worker. Read  [the proposal I cite above](https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/jsapi.md), which might clarify things a bit.

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