Re: Comments on Web Payments HTTP API 1.0

> On Apr 12, 2016, at 1:44 PM, Ian Jacobs <ij@w3.org> wrote:
> 
> Manu, Dave,
> 
> Thank you for proposing:
> 
>  Web Payments HTTP API 1.0
>  https://w3c.github.io/webpayments/proposals/web-payments-http-api/
>  9 April 2016

Hi Manu and Dave,

I have some additional questions and observations.

It seems that the spec seeks to define a Web service that listens for payment requests made
via HTTP POST. I can imagine this Web service being either of the following:

* A Payment App  (I think the Payment App registration spec is looking for something like this; see 6.2 [1]).
* A Mediator

The draft spec seems to propose the latter approach.

The Web service could operate either locally (on the user’s phone, for example) or remotely (in the cloud).
(I am ignorant about the extent to which native operating systems support HTTP communications among apps.)

I think the spec could useful show an example of when this would be invoked. Is this the following scenario the sort
you envision?

 - The user sets up a Web service that responds to payment requests. This service is identified by a URL.
 * The user installs a parking app to make payments in local parking lots. The user registers the Web service (via URL) with the parking
   app. (The user may not know the URL of the payment service if this is all managed locally, just like users do not know the file names of
   things they install.)
 * On arrival, the user launches the parking app which asks the user to confirm the identity of the parking lot (e.g., by typing in a number, or scanning a
   QR code, or by confirming the location proposed through GPS, or some other mechanism).
 * The parking app prompts the user to pay for a certain amount of time. The user confirms.
 * This causes the parking app to send a payment request (via HTTP POST) to the Web service. The user authorizes payment and the parking
    app receives the response.
 * While at lunch, the parking app alerts the user that the time is about to expire and prompts the user to pay for another 30 minutes.
   The user authorizes the payment and enjoys dessert.

(A even more “IOT” scenario has parking app running in the head unit of the user’s car.)

If this is the sort of scenario you have in mind, then I assume the primary use case is for native apps. I say that
because if the parking app is an in-browser Web app, then I would expect the app developers to use the paymentRequestAPi.

If the goal of the spec is to define a Web service, then I would look for it to address topics such as:

 * Query parameters available when invoking the Web service
 * Response codes and error conditions
 * Security considerations
 * Extensibility and versioning

Your draft does partially touch on these topics (in some places with placeholder section titles).

If the above is an accurate read of the spec, then I think it could be reworked to make it much clearer that it is defining
a Web service, with reference to components (Mediator, Payment App) that I expect to see defined in their own specs.

Ian

[1] https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html#submitting-the-paymentrequest-to-the-payment-app

[Snip comments on spec text]


> ====================
> Observations
> 
> Right now the heart of the specification is the flow described in
> section 2. It seems to me that the flow could be described in part
> in terms of "Mediator" functionality:
> 
> 1) When payer attempts to buy something from the payee,
>    payer's user agent fetches offer via HTTP.
> 2) Payer's user agent invokes mediator, which prompts user to
>    choose a payment application, launches the payment application,
>    hands the payment application the payment request, and
>    then payment processing happens
> 3) Payer's payment app returns the payment response to the payee.
>    (But see my question above: does the flow systematically return
>     the response to the payee?)
> 
> AdrianHB has proposed a mediator spec:
> https://github.com/w3c/browser-payment-api/issues/138
> 
> I agree we should define the mediator in its own specification
> including information about computing the intersection of
> accepted payment methods, any requirements for user interaction,
> and whatever else we deem in scope.
> 
> Then it seems that the HTTP API specification could focus on:
> 
>  - How the user agent retrieves the offer and communicates
>    it to the mediator via HTTP.
>  - How the payment application communications the reponse
>    to the payee via HTTP.
> 
> So at a high level, I suggest:
> 
> * We cover payment app registration and management in a separate spec.
> * We cover mediator behavior in a separate spec.

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447