Re: Updates to Payment Apps wiki page

On 18 May 2016 at 15:59, Håvard Molland <haavardm@opera.com> wrote:

> Ah, right. I got the impression from both the spec and the discussion in
> emails that you wanted HTTP approach only. If that is not so, that is great
> and we seem to be on equal terms there.
>
> That said I find the "huge learning curve" a bit of a weak argument. I
> believe that any company that wants to integrate their payment apps with
> merchant websites or other merchants that initiates the payment requests
> using JavaScript should understand that side of the infrastructure.
>

+1 I think you would struggle to find a developer today that would call
JavaScript a "huge learning curve"


>
> Håvard
>
>
> On Fri, May 13, 2016 at 9:56 PM, Adrian Hope-Bailie <adrian@hopebailie.com
> > wrote:
>
>> Håvard,
>>
>> My argument is not against the Javascript approach, it is against that
>> approach only instead of an HTTP approach.
>>
>> If we only support javascript integration everyone must write javascript
>> to be able to publish a payment app. That means that the company that
>> writes a hardware based app that is written on some embedded platform or
>> the old school payment gateway that only has PHP development skills has a
>> huge learning curve to be part of this ecosystem.
>>
>> If the only way for these apps to integrate is to use some popular
>> javascript library, that takes the request and posts it over HTTP, then
>> we'd find 100s of apps using the same or similar piece of javascript
>> bridging code and realise we should have just standardized this in the
>> first place.
>>
>> 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.
>>
>> Adrian
>>
>> On 13 May 2016 at 16:42, Håvard Molland <haavardm@opera.com> wrote:
>>
>>>
>>> On Thu, May 12, 2016 at 5:29 PM, Adrian Hope-Bailie <
>>> adrian@hopebailie.com> wrote:
>>>>
>>>> On 11 May 2016 at 12:49, Håvard Molland <haavardm@opera.com> wrote:
>>>>
>>>>>
>>>>> Can you give an example where a HTTP gateway answers to a payment
>>>>> request POSTed from a browser, where the gateway doesn't have to produce
>>>>> a JavaScript payment app as a response?
>>>>>
>>>>
>>>> There are many. In fact any distributed app that either has no user
>>>> interface or the user interface is not in the browser.
>>>>
>>>
>>> Thanks for the examples! That makes it much more easy to discuss the
>>> matter.
>>>
>>>
>>>> Example 1 - No UI:
>>>> 1. Browser -- fetch(HTTP POST: Payment Request)--> Payment App's HTTP
>>>> endpoint
>>>> 2. Payment App processes request and based on internal logic generates
>>>> payment response
>>>> 3. Payment App --(HTTP response: Payment Response) --> Browser
>>>>
>>>
>>> Where does the user authentication happen in this case? At the merchant
>>> site? Upfront?
>>>
>>> Example 2 - UI is on a native mobile app:
>>>> 1. Browser --fetch(HTTP POST: Payment Request)--> Payment App's HTTP
>>>> endpoint
>>>> 2. Payment App processes request and generates authentication request
>>>> 3. Payment App --(?proprietary?: Authentication Request via push
>>>> message)--> Native Mobile App
>>>> 4. User authorizes transaction on phone
>>>> 5. Native Mobile App --(?proprietary?: Authentication Response)->
>>>> Payment App
>>>> 6. Payment App --(HTTP response: Payment Response) --> Browser
>>>>
>>>>
>>> It's my impression that the OS's here will provide means for sending the
>>> request directly to the native app instead of going through HTTP server.
>>> For instance using intents on Android.
>>>
>>>
>>>> The HTTP option does not preclude a local ServiceWorker intercepting
>>>> the POST so it never actually leaves the browser
>>>>
>>>> Example 3 - ServiceWorker with no UI:
>>>> 1. Browser -- fetch(HTTP POST: Payment Request)--> Intercepted by
>>>> ServiceWorker Payment App
>>>> 2. Payment App processes request and generates payment response
>>>> 3. Payment App --fetch.respondWith( Payment Response)) --> Browser
>>>>
>>>> Example 4 - ServiceWorker with UI:
>>>> 1. Browser --fetch(HTTP POST: Payment Request)--> Intercepted by
>>>> ServiceWorker Payment App
>>>> 2. Payment App processes request and renders cached HTML
>>>> 3. Payment App --navigator.payments.respond( Payment Response)) -->
>>>> Browser
>>>>
>>>
>>> This seems to complicate the development of web payment apps.
>>>
>>> There are different ways we could handle this in-browser payment app
>>>> case.
>>>>
>>>> Example 5 - Simple web based payment app:
>>>> 1. Browser --(HTTP POST: Payment Request)--> Payment App's HTTP
>>>> Endpoint
>>>> 2. Payment App --(HTTP response: HTML Web Application Start Page) -->
>>>> Browser
>>>> 3. Browser opens a new tab, special payment dialogue or iframe over the
>>>> original website and renders HTML web app.
>>>> 4. User interacts with app and when they have accepted the payment the
>>>> website calls navigator.payments.respond(...)
>>>>
>>>> Example 6 - ServiceWorker with UI and local-only static content:
>>>> 1. Browser --fetch(HTTP POST Payment Request)--> Intercepted by
>>>> ServiceWorker Payment App
>>>> 2. Payment App ignores request details and returns cached static HTML
>>>> 3. onload the web app calls navigator.payments.getPaymentRequest()
>>>> which returns the current payment request to the app as an object it can
>>>> process locally using JavaScript
>>>> 4. User interacts with app and when they have accepted the payment the
>>>> website calls navigator.payments.respond(...)
>>>>
>>>
>>> These also seem more complicated than using a JavaScript API, as 5
>>> requires scripting on the server to produce the app, and example 6 requires
>>> ServiceWorkers.
>>>
>>>
>>>>
>>> Architecturally I think HTTP is the right approach, the hybrid solution
>>>> simply provides a convenient addition for those that don't want to deal
>>>> with HTTP. This is only the case where the payment app is a web app that
>>>> will run in the same browser as the payee website. (i.e. A very limited
>>>> scope of the many possible use cases)
>>>>
>>>
>>> This argument could be turned around, where HTTP is convenient for those
>>> that doesn't want to deal with JavaScript. You could also take your
>>> argument further where the payment app would need to post the response back
>>> to the app server which then converts it to json, removing the payment app
>>> JavaScript API completely (FTR I don't want this solution :) ). Right now I
>>> find the async behavior of receiving the request through HTTP and
>>> responding in JavaScript a bit unclean.
>>>
>>> I'm not against allowing sending the payment request through HTTP
>>> though, as it does open up for some interesting use cases (say using a
>>> payment app on the phone after having browsed the merchant site on a
>>> desktop computer), and it makes life easier for non-browser clients in some
>>> cases.
>>>
>>> However, I don't see why JavaScript API should be disallowed. 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.
>>>
>>> Cheers,
>>> Håvard
>>>
>>>
>>>
>>> In the last example the payment app would install itself like a
>>>> ServiceWorker and could install the whole app locally in the cache.
>>>>
>>>>
>>>>>
>>>>>
>>>>> Håvard
>>>>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>