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

Re: [w3c/webpayments] Letting the payment app decide between HTTP and Javascript communication (#130)

From: Tommy Thorsen <notifications@github.com>
Date: Thu, 19 May 2016 23:26:48 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Message-ID: <w3c/webpayments/issues/130/220527384@github.com>
> I'd say yes actually. If the processing of the payment request is complex then it might be preferable to do this server-side and to return an HTML UI with just light client-side processing (maybe just a confirmation page).

You could of course pass the payment request to the backend from javascript, for further processing. I'm not a web developer, but I believe this is a fairly common thing to do, as it lets the payment app display a nice progress UI while the backend performs complex, and possibly time-consuming, processing of the payment request.

> No, they would call ServiceWorkerContainer.register(), which would cause the local payment app to be activated whenever an appropriately-scoped POST is called. The local payment app would then handle this POST response in the same way as a remote payment app does.

This seems promising, but I am unfortunately completely unfamiliar with service workers. I guess I have some reading up to do. If we could make a proof-of-concept to establish that this is a convenient way for payment app implementors to deal with POST requests, this might be the path forward.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Received on Friday, 20 May 2016 06:28:11 UTC

This archive was generated by hypermail 2.3.1 : Friday, 20 May 2016 06:28:13 UTC