Re: Updates to Payment Apps wiki page

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