Re: Payment Apps Proposal

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.