Re: Updates to Payment Apps wiki page

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