Re: Updates to Payment Apps wiki page

On 11 May 2016 at 12:49, Håvard Molland <haavardm@opera.com> wrote:

>
>
> 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.
>>
>
> This confuses me, but there might be something I've misunderstood.
>
> 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.
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

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


> Since the gateway must (?) in these cases respond with an JavaScript app
> anyway, why is it easier that the payment request goes via the server
> instead of being handed directly over to this payment app using JavaScript
> (which then can post the details to the server in any format they'd like).
> Also, from the server perspective, JavaScript API seems simpler, since this
> JavaScript may be served as static pages without any server logic to
> produce the app.
>

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


>
> If the payment request is initiated through the HTTP API, I do see the
> value of using POST, but that seems like a separate problem. I don't see
> that these needs to intercept.
>

The value of using HTTP for ALL requests is that it's neutral. It's a
protocol based integration and not one that requires both systems to have
components running on the same platform in the same process (which a
language based integration does).


>
> It also feels weird that the communication between the payee website and
> the payment app is asynchronic, as in, the request is sent via POST but
> answered via JavaScript (in the case where the server responds with html)
>


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)

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(...)

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 Thursday, 12 May 2016 15:30:13 UTC