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

I know I've gone on record as saying that either approach is fine with me, as POST can be adapted to JS via service workers, and JS can be turned into POST with XHR; however, I've been looking more closely at how the interaction works, especially in the context of browser components and native apps, and have been increasingly finding POST to be an awkward fit.

So I'd like to throw my hat in with Tommy and Anders in favoring a JS approach over a POST one. At a high level: the URL pointing to the payment app would be expected to contain javascript. This JS is loaded into a windowless context. If it needs to display information to the user, it can use `window.open()` and load its UX into that window.

The payment request would be provided by the mediator via some a javascript affordance -- e.g., using [`window.postMessage()`](https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API) -- which could then be used to provide a response from the script.

---
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-230543922