Re: Updates to Payment Apps wiki page

>
> In my opinion, the disadvantage of the HTTP mechanism is that it does not
>> allow the payment app to display a UI. Many payment apps probably want to
>> have the user log in or select between payment instruments etc.
>
>
> I disagree. The idea is that the browser will send the payment request via
> an HTTP POST to the payment app endpoint. If the response is HTML then the
> browser will render this in a new tab/dialogue.
> The user can then interact with that web application and when the app is
> ready to submit the payment response it will call a JavaScript API to do so.
> I have described this in the wiki page as the hybrid response approach.


Aha, I hadn't read that far down yet. The hybrid approach is the way I
imagined we'd have to do it after reading both the Payment Apps proposal
and the HTTP API proposal, and I think that seems like a sensible approach.


On Tue, May 10, 2016 at 1:39 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> Hey Tommy,
>
>
>> In my opinion, the disadvantage of the HTTP mechanism is that it does not
>> allow the payment app to display a UI. Many payment apps probably want to
>> have the user log in or select between payment instruments etc.
>>
>
> I disagree. The idea is that the browser will send the payment request via
> an HTTP POST to the payment app endpoint. If the response is HTML then the
> browser will render this in a new tab/dialogue.
>
> The user can then interact with that web application and when the app is
> ready to submit the payment response it will call a JavaScript API to do so.
>
> I have described this in the wiki page as the hybrid response approach.
>
>>
>>
>> If we go down the route of using a JavaScript API then we will require
>>> browsers to add new integrations in future to support different payment app
>>> implementation types whereas if we use HTTP then we can define this once
>>> and it should support all future implementation types.
>>
>>
>> Why would this be necessary? The payment app proposal
>> <https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html>
>> with the installable payment apps looks flexible enough that it should be
>> able to handle new payment app types.
>>
>
> I agree, that proposal uses the HTTP approach I am advocating. i.e. Send
> the request via HTTP and then the response either via JavaScript or HTTP
> depending on the app type.
>
> On 10 May 2016 at 13:28, Tommy Thorsen <tommyt@opera.com> wrote:
>
>> Hi Adrian,
>>
>> My assertion is that we should focus on defining how a browser passes a
>>> payment request over the Web (irrespective of how the app that receives it
>>> is implemented). This implies that we need a platform agnostic mechanism
>>> like HTTP.
>>>
>>
>>
>> The alternative is to focus purely on payment apps that run in the
>>> browser in which case it might make sense to use a Javascript API to pass
>>> the payment request to the in-browser payment app (although the HTTP
>>> mechanism would still work it's no longer the only option).
>>
>>
>> In my opinion, the disadvantage of the HTTP mechanism is that it does not
>> allow the payment app to display a UI. Many payment apps probably want to
>> have the user log in or select between payment instruments etc.
>>
>> If we go down the route of using a JavaScript API then we will require
>>> browsers to add new integrations in future to support different payment app
>>> implementation types whereas if we use HTTP then we can define this once
>>> and it should support all future implementation types.
>>
>>
>> Why would this be necessary? The payment app proposal
>> <https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html> with
>> the installable payment apps looks flexible enough that it should be able
>> to handle new payment app types.
>>
>> - Most existing payment gateways process HTTP requests so this will
>>> require all of these to make significant investment in new technology to
>>> accept payment requests from the browser.
>>>
>>> IJ: I don't understand this point. They can wrap their HTTP call inside
>>> the JavaScript. Why does this imply more investment than having to change
>>> their HTTP interface to align with a new HTTP-based standard?
>>>
>>> AHB: Correct but this requires them to write an entirely new component,
>>> a javascript payment app, which they likely never have needed before. By
>>> forcing these gateways to push JavaScript to client browsers you are asking
>>> them to do something they potentially have no operational experience doing
>>> and potentially no skills to do or maintain.
>>>
>>> In contrast they could simply add a new HTTP endpoint to their existing
>>> HTTP API that accepts a payment request and transforms this into the format
>>> they receive on other end-points.
>>>
>>> For most gateways this is very familiar part of their operations and
>>> would dovetail into their existing systems much more easily.
>>>
>>>
>> What kind if gateways are these? Examples? (I'm asking because I'm
>> genuinely curious and do not have a lot of knowledge in this area).
>>
>> I'm not super fond of the argument that we should limit ourselves so that
>> some implementors will not have to learn anything new. I think we should
>> strive to create the best payment specification we can, and in that
>> process, use the technology that fits best.
>>
>> On the flip side to your argument, a lot of payment providers already
>> have javascript SDKs (like PayPal, Mastercard or Visa). Have a look here
>> <https://people.opera.com/tommyt/pay.php> for a proof-of-concept
>> web-based payment app I hacked together in an afternoon, which consists of
>> just a few lines of javascript, wrapping the Visa Checkout payment system.
>> For cases like this, the javascript approach makes it very easy to retrofit
>> an existing payment solution.
>>
>> -Tommy
>>
>>
>>
>> On Tue, May 10, 2016 at 11:45 AM, Adrian Hope-Bailie <
>> adrian@hopebailie.com> wrote:
>>
>>> Thanks Ian.
>>> Answers to your questions below:
>>>
>>> Regarding disadvantages of a JavaScript API:
>>>
>>> - Most existing payment gateways process HTTP requests so this will
>>> require all of these to make significant investment in new technology to
>>> accept payment requests from the browser.
>>>
>>> IJ: I don't understand this point. They can wrap their HTTP call inside
>>> the JavaScript. Why does this imply more investment than having to change
>>> their HTTP interface to align with a new HTTP-based standard?
>>>
>>> AHB: Correct but this requires them to write an entirely new component,
>>> a javascript payment app, which they likely never have needed before. By
>>> forcing these gateways to push JavaScript to client browsers you are asking
>>> them to do something they potentially have no operational experience doing
>>> and potentially no skills to do or maintain.
>>>
>>> In contrast they could simply add a new HTTP endpoint to their existing
>>> HTTP API that accepts a payment request and transforms this into the format
>>> they receive on other end-points.
>>>
>>> For most gateways this is very familiar part of their operations and
>>> would dovetail into their existing systems much more easily.
>>>
>>>
>>> - Defines a standard for cross application integration at the language
>>> level as opposed to at the protocol level. This forces all payment apps (or
>>> at least part of them) to be written in JavaScript.
>>>
>>> IJ: But if the WG agrees that the right scope is "browser-based Web
>>> apps" this is not a problem?
>>>
>>> AHB: Correct, hence my assertion that limiting the scope would be a bad
>>> decision. It would open us up to making a design decision that is very
>>> short-sighted. I am yet to hear a good argument for limiting the scope to
>>> browser-based payment apps only.
>>>
>>>
>>> With regard to advantages of the HTTP approach
>>>
>>> - Most payment gateways already accept payment requests via HTTP
>>>
>>> IJ: What is the cost of changing those gateways to handle a new standard?
>>>
>>> AHB; For the majority that already accept payment initiation requests
>>> via an HTTP request (or redirect from the merchant page) very low. They can
>>> likely re-use the whole of their existing stack and simply accept the new
>>> format payment request at a new endpoint. transfrom it and redirect it to
>>> their existing endpoint. Then they can follow similar logic to transform
>>> their responses.
>>>
>>>
>>> On 9 May 2016 at 23:43, Ian Jacobs <ij@w3.org> wrote:
>>>
>>>>
>>>> > On May 9, 2016, at 10:03 AM, Adrian Hope-Bailie <
>>>> adrian@hopebailie.com> wrote:
>>>> >
>>>> > Hi Ian and WG,
>>>> >
>>>> > I have made some updates to the payment apps wiki as requested:
>>>> >
>>>> >       • I added a comment about us needing to clarify our scope. I
>>>> think a lot of what was in there assumed that the scope was only payment
>>>> apps that run in a browser and ignores the possibility of other apps that
>>>> can still be interfaced from a browser over the Web.
>>>> >       • I added a few definitions to differentiate between
>>>> browser-based and web-based apps (per scoping question above).
>>>> >       • I also dropped the hybrid and web-technology apps as I'm not
>>>> sure these have any impact on integration with a browser (i.e. an app
>>>> either runs in the browser or doesn't which is all that matters from the
>>>> perspective of integration with the browser).
>>>> >       • I added the following line to the display text:
>>>> > "The browser should display matched payment apps in an order that
>>>> corresponds with the order of supported payment methods supplied by the
>>>> payee"
>>>> >       • I made changes to the advantages and disadvantages of the
>>>> invoking and response sections based on discussions with Ian.
>>>> > (Although I'm still not sure I agree that JavaScript encapsulation
>>>> has an advantage of flexibility, I think it's the opposite)
>>>> >       • I corrected the steps in the JavaScript encapsulation
>>>> approach to include passing the response to the browser.
>>>> >       • Added a hybrid response approach
>>>> >       • Made some minor changes to the data collection points
>>>>
>>>> Thanks, Adrian. I made some edits to your text, primarily to “tighten
>>>> things up” (and mostly by moving things around or tweaking the text).
>>>>
>>>> This seems like a good WG call question: whether the scope of its
>>>> initial work will be web-based payment apps or (the subset) browser-based
>>>> payment apps.
>>>>
>>>> Ian
>>>>
>>>> --
>>>> Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
>>>> Tel:                       +1 718 260 9447
>>>>
>>>>
>>>>
>>>>
>>>
>>
>