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

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

From: adamroach <notifications@github.com>
Date: Tue, 05 Jul 2016 10:22:46 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Cc:
Message-ID: <w3c/webpayments/issues/130/230543922@github.com>
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
Received on Tuesday, 5 July 2016 17:23:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 5 July 2016 17:23:21 UTC