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>
Cc:
Message-ID: <w3c/webpayments/issues/130/220527384@github.com>
@adrianhopebailie 
> 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.

@adamroach 
> 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:
https://github.com/w3c/webpayments/issues/130#issuecomment-220527384
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