Re: Updates to Payment Apps wiki page

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.

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

Received on Wednesday, 18 May 2016 14:00:34 UTC