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: Fri, 20 May 2016 06:10:26 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Message-ID: <w3c/webpayments/issues/130/220601206@github.com>
To elaborate a bit on my motivation for creating this issue (and the corresponding PR): I strongly prefer APIs (and specifications) that are simple and obvious. At some point, browser vendors (like myself) and payment providers are going to have to get their hands dirty and implement the things that we have specified. What are their reactions going to be? Will they say `"Right, I get it! This is how it obviously should work"`, or will their reaction be `"Wtf? Why do I have to do it this way? This makes no sense"`.

If we want this spec to be widely adopted, it would be beneficial to us if the specification prompts a reaction like the first of those two responses. But when I look at the HTTP POST with the subsequent switch on mime-type, I just fear that we're leaning towards triggering the latter response.

I've been looking into the service worker approach to intercepting POST messages today. The preliminary results are in the form of a modified version of the Visa Checkout based payment app I made earlier and is available [here](https://tommythorsen.github.io/visa-checkout-payment-app/). The source code is available [here](https://github.com/tommythorsen/visa-checkout-payment-app). (Note that it doesn't actually parse the POST at the moment, but the rest of the communication between the web page and the service worker is in place. Also, the first time you navigate to the app you get a white page because the service worker isn't registered yet. Reload to get the proper app). It seems like this would be a working approach, but I wouldn't go so far as to call it convenient...

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 13:10:55 UTC

This archive was generated by hypermail 2.3.1 : Friday, 20 May 2016 13:10:57 UTC