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

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

From: Tommy Thorsen <notifications@github.com>
Date: Wed, 18 May 2016 04:35:34 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Message-ID: <w3c/webpayments/issues/130@github.com>
The current Payment Apps spec proposal suggests that communication between the user agent and the payment app is initiated by means of a POST, but discussions (for instance [here](https://github.com/w3c/browser-payment-api/issues/16) indicate that people are also positive to using a javascript method to pass the payment request to the payment app. For instance something like this:

//After the payment app loads ask the browser for the current request that it must process
var paymentRequest = navigator.payments.getRequest();

However, if we want to have the javascript getRequest() function above, then it does not seem very elegant to also pass the payment request object to the payment app by means of HTTP POST.

It was suggested in a mail thread that we could let the payment app itself decide whether to use HTTP or Javascript at the time of registration.

HÃ¥vard Molland said:
>  The method for sending the request to the payment app could be set in the app manifest, and this would make life easier for the browser payment app developers.  I certainly don't agree that browser payments apps are corner cases.

@adrianhopebailie answered:
> I certainly like the idea of supporting both and allowing the app to specify which integration it uses when it is registered. Adam Roach and Ian suggested to me that we consider something like the IdP registration in WebRTC so we'll see where we can weave that into the payment apps proposal.

I propose that we change the payment app spec proposal so that the decision of whether to use HTTP or Javascript is not based on the mime type of the payload returned from an HTTP POST, but that the decision is based on a property in the payment app manifest (or possibly some other registration-time mechanism).

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Received on Wednesday, 18 May 2016 11:36:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 18 May 2016 11:36:06 UTC