W3C home > Mailing lists > Public > public-payments-wg@w3.org > May 2016

RE: Updates to Payment Apps wiki page

From: David Ezell <David_E3@VERIFONE.com>
Date: Tue, 10 May 2016 13:54:13 +0000
To: Adrian Hope-Bailie <adrian@hopebailie.com>, Ian Jacobs <ij@w3.org>
CC: Payments WG <public-payments-wg@w3.org>
Message-ID: <BLUPR03MB133130EDDBA31E5CFC9B5783C8710@BLUPR03MB1331.namprd03.prod.outlook.com>
Thanks Adrian and Ian:

FWIW, as a WG member (representing NACS) I’m in full agreement with Adrian’s position below:
>         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.

My concern is about the logistics of a “v1” vs. “v2”:
* does "v1" mean FPWD of some subset of documents, or CR, Rec, etc.?
* is there an expected timeframe?

If you believe that "v2" (if that's where HTTP API goes) is essential, knowing if it's expected in 2 months or 2 years is helpful in giving feedback.

I'll look for an open thread...

Best regards,
David

From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com] 
Sent: Tuesday, May 10, 2016 5:25 AM
To: Ian Jacobs
Cc: David Ezell; Payments WG
Subject: Re: Updates to Payment Apps wiki page

Hi David,
Ian is correct although I will add that the scope will affect the design decisions we take which may be difficult to change in future.
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).
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.

I think it's clear that I prefer the HTTP approach but I think we should hear from the group if there are good reasons to limit ourselves to just a JavaScript API.
I also note that the Browser Extensions CG [1] is starting to make progress on a standard browser extensions mechanism which will be an interesting one to watch wrt interfacing payment apps implemented as browser extensions.

Adrian

[1] https://www.w3.org/community/browserext/


On 10 May 2016 at 04:51, Ian Jacobs <ij@w3.org> wrote:

> On May 9, 2016, at 7:01 PM, David Ezell <David_E3@VERIFONE.com> wrote:
>
> Hello all:
>
> I have a question.
> Ian wrote:
>> 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.
>
> What does "initial work" mean, exactly, in terms of documents and rec-track progress?

Hi David,

Part of the exercise of creating this document [1] has been to help us establish a shared
understanding of terms and scope.

AdrianHB asks a scope question in the payment apps wiki: does the WG want to focus
on browser-based payment apps initially (that is: those that run in a JavaScript environment
in the browser), or a broader class of web-based payment apps (which includes the browser-based
apps but also HTTP services, for example).

Presumably the WG could choose to limit a “v1” Recommendation to browser-based
apps, then build from there. Or the WG could choose to work on the broader class
in v1.

Ian

[1] https://github.com/w3c/webpayments/wiki/PaymentApp_Notes

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs

Tel:                       +1 718 260 9447



Received on Tuesday, 10 May 2016 14:39:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 10 May 2016 14:39:04 UTC