- From: Manu Sporny <notifications@github.com>
- Date: Thu, 11 Feb 2016 08:11:27 -0800
- To: w3c/webpayments <webpayments@noreply.github.com>
- Cc: webpayments <public-payments-wg@w3.org>
Received on Thursday, 11 February 2016 16:12:26 UTC
Just chiming in to say I think this is important, but don't have the time to devote to it right now. Here's why I think it's important: Without a well-defined communication channel between payment app and merchant website, I don't think we can fulfill a number of our non-browser-based use cases. I'd say that the majority of the group doesn't understand that not standardizing this means that there are potentially no 3rd party payment apps that aren't tightly coupled. For example, actual native applications running on a mobile device. So, while I'm sure Google, Microsoft, and Apple would have no problem writing a native payment app for their mobile platforms that communicate w/ a merchant, I doubt a non-multi-billion-dollar-multinational would have an easy time doing such a thing. This also asks the question - how does a non-browser-based flow get a request and respond to a request via the HTTP API? What communication channel is used for that? This is why we have a 'paymentRequestService' URL in the HTTP API: http://web-payments.github.io/web-payments-http-api/#h-payment-app-registration --- Reply to this email directly or view it on GitHub: https://github.com/w3c/webpayments/issues/76#issuecomment-182938005
Received on Thursday, 11 February 2016 16:12:26 UTC