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

RE: Concerns around Web Payments HTTP API de-prioritization

From: David Ezell <David_E3@VERIFONE.com>
Date: Sun, 31 Jan 2016 18:15:54 +0000
To: Manu Sporny <msporny@digitalbazaar.com>, Web Payments IG <public-webpayments-ig@w3.org>, Web Payments Working Group <public-payments-wg@w3.org>
Message-ID: <BY1PR03MB13380EF8E9684F9214B32A04C8DD0@BY1PR03MB1338.namprd03.prod.outlook.com>
Hi Manu:

Thanks for the heads up.  The short answer to "does this concern you as well?" is "It concerns me that it concerns you." 
I think the position of the WG is worth clarifying. 

Note: I have faith in the chairs and W3C staff to keep things on track. 
That said, I also think it's worthwhile to avoid a serious problem through discussion.
I want to commend the WG for "doing what it takes" to get points on the board.  I have no qualms about that.  Back to the topic...

I would like to mention the following points:

First point, he charter for the WG is (in my opinion) unequivocal in calling for 
"3.1 Web Payments Messages Recommendation"
The charter doesn't call for a Note or an "understanding;"  it calls for a Recommendation.
If there is disagreement that "Messages Recommendation" implies an HTTP API, then NOW is the time to call that out.  To me it's obvious, but I'm willing to be corrected.

Second point, the Messages Recommendation comes before any other deliverables in the charter.
I'm fine with the WG ordering it's work for efficient execution.  Order may not mean anything in terms of timing, but it does make the work item stand out.

Third point, what you designate as "non-interactive" scenarios includes almost all applications in "brick-and-mortar" or (the increasingly visible) hybrid use cases.  

Finally, web browser API are very helpful.  For functions (like GPS) that mainly talk to lower levels of a local system, relying on the browser from the API down is OK.  But for situations that are designed to connect stakeholders over the web, message definitions (i.e. HTTP APIs) are essential.  In supporting the charter, NACS is essentially supporting HTTP APIs, while at the same time NACS is happy (maybe even very happy) to have browser APIs that make those messages easy to use.  But while NACS understands that browser APIs may be essential to make the HTTP API successful, not having the HTTP API leaves the most of the use cases we care about unaddressed.

Summary, I think the charter is correct.  If I've messed up something, please let me know.

Best regards,

> -----Original Message-----
> From: Manu Sporny [mailto:msporny@digitalbazaar.com]
> Sent: Saturday, January 30, 2016 11:48 AM
> To: Web Payments IG; Web Payments Working Group
> Subject: Concerns around Web Payments HTTP API de-prioritization
> During the last Web Payments WG call, the group decided to push the
> delivery of the First Public Working Draft of the HTTP API back to June
> 2016 (it had been scheduled for March 2016). The reasoning was that we
> don't have the bandwidth to do a thorough review of both by the March
> 2016 deadline.
> I +1'ed this proposal because I agreed with the notion that we don't have
> enough people capable of doing a thorough spec review of the Web
> Payments HTTP API by March 2016. The votes seemed to be indifferent to the
> fact that we were de-prioritizing the HTTP API. That's deeply concerning to
> me.
> To be clear, I view the HTTP API as equally important as the Browser API. It has
> been noted that this view may not be shared by the rest of the group. I'd like
> to understand where the group stands on the importance of the Web
> Payments HTTP API.
> In an attempt to be abundantly clear:
> Without the Web Payments HTTP API, we have no solution for non-interactive
> payments via the Web. Non-interactive (aka automated) payments constitute
> roughly 91% of the total value of payments in the UK[1] and almost 50% of US
> ACH network transaction volume[2].
> The Browser API is for interactive payments and is designed around the
> notion that there will be someone there to click a button to initiate the
> payment.
> What was surprising to me during the poll two days ago was not that we were
> deprioritizing the HTTP API to focus on the Browser API, but that a number of
> WPWG members said that they were either 1) indifferent about the HTTP API,
> or 2) didn't understand why the HTTP API was important.
> The Web Payments HTTP API is the thing that gives us non-interactive
> payments over the Internet and the Web. We have de-prioritized it. Do you,
> as a group member, feel indifferent about that decision? Or does this concern
> you as well?
> -- manu
> [1]http://www.paymentsuk.org.uk/news-events/news/new-report-reveals-

> record-73-billion-automated-payments-made-2014
> [2]https://www.nacha.org/news/ach-volume-increases-23-billion-payments-

> 2014
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Web Payments: The Architect, the Sage, and the Moral Voice
> https://manu.sporny.org/2015/payments-collaboration/


Received on Sunday, 31 January 2016 18:16:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:13 UTC