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

@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