W3C home > Mailing lists > Public > public-payments-wg@w3.org > July 2016

Re: Payment Apps Proposal

From: Rouslan Solomakhin <rouslan@google.com>
Date: Tue, 05 Jul 2016 08:11:03 +0000
Message-ID: <CAMMzaWFj28fWkgDnBgF0F_Gd5wUEFd_QMmm=miQin8Xp1yUYLA@mail.gmail.com>
To: Adrian Hope-Bailie <adrian@hopebailie.com>, Payments WG <public-payments-wg@w3.org>
On Mon, Jul 4, 2016 at 12:51 PM Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> This specification proposes that payment apps are invoked by the browser
> sending an HTTP POST to an endpoint URL defined by the app during
> registration. The payment app can either return an HTML response which is
> rendered by the browser or a JSON response which is parsed by the browser
> as the payment response (and passed directly to the calling website).
>
> The advantage of this approach is that the payment app does not need to
> define UI (through HTML) if it is able to perform user interaction and
> payment auth through an alternative channel. For example a payment app may
> consist of a native mobile app and a remote web service. When the payment
> request is posted to the web service URL the webservice sends a push
> message to the user's mobile phone and the native app prompts the user to
> authorize the transaction following which the webservice responds to the
> browser with a JSON encoded payment response.
>

+1. Glad you've thought through the desktop-to-phone flow.


> An offline/local only payment app can still be defined by installing a
> ServiceWorker during registration that has an event listener for the fetch
> event. When the browser attempts the HTTP POST the ServiceWorker will
> process the request locally and may respond without the request ever going
> online. (e.g.
> https://gist.github.com/adrianhopebailie/a79f0a32ac5af54dd7c0d2200b251bf3)
>

+1. Glad this proposal handles the offline case as well.
Received on Tuesday, 5 July 2016 08:11:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 5 July 2016 08:11:48 UTC