Re: Concerns around Web Payments HTTP API de-prioritization

I'm a strong +1 on the need to work out payments for non-interactive use
cases, which by implication means, an API that's not dependent on a browser.
(I'm also open to ideas about how this could be done and don't want to
assume it will be an HTTP API - although that seems most likely)

I'd like to see some more detail on non-interactive use cases or at least
some demo's or thoughts around how these would work.

I suspect the group is finding it very easy to work on the browser API
because it's easy to relate it to the way things work today.
What can we do to acheive a similar level of familiarity for
non-interactive use cases?

On 1 February 2016 at 19:08, Telford-Reed, Nick <
Nick.Telford-Reed@worldpay.com> wrote:

> To weigh in here wearing my Worldpay hat, not my chairperson's hat, I
> would say that an non-browser API is important.
>
> It seems to me that the consensus was reached, from my chair perspective,
> simply as a reflection of work prioritisation and an indication of the
> mountain we have to climb. There is a lot of energy around the browser API
> and lots of people to do work. There are (it seems to me) fewer
> participants who are prepared to push ahead on the non-interactive API. I
> suppose that also reflects the observation (which is reflected in the
> original justification of the WG) that there is a lot of opportunity in
> improving the consistency of the user experience of payments in the web and
> so the obvious  place to fix that first is in interactive browser-based
> interactions.
>
> Something that I would really like to see is more representation in the
> working group from the "creditor/payee/merchant" side of the equation.
> Hopefully the outreach activities in San Franscisco's F2F will help that.
>
> Nick
>
>
> --
> Nick Telford-Reed
> e: nick.telford-reed@worldpay.com | m: +447799473854 | t: +44 203 664 5069
>
> > -----Original Message-----
> > From: David Ezell [mailto:David_E3@VERIFONE.com]
> > Sent: 31 January 2016 18:16
> > To: Manu Sporny; Web Payments IG; Web Payments Working Group
> > Subject: RE: Concerns around Web Payments HTTP API de-prioritization
> >
> > 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,
> > David
> >
> >
> > > -----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/
> > >
>
> This e-mail and any attachments are confidential, intended only for the
> addressee and may be privileged. If you have received this e-mail in error,
> please notify the sender immediately and delete it. Any content that does
> not relate to the business of Worldpay is personal to the sender and not
> authorised or endorsed by Worldpay. Worldpay does not accept responsibility
> for viruses or any loss or damage arising from transmission or access.
>
> Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority
> No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct
> Authority No: 504504), Worldpay AP Limited (Company No: 05593466 /
> Financial Conduct Authority No: 502597). Registered Office: The Walbrook
> Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial
> Conduct Authority under the Payment Service Regulations 2009 for the
> provision of payment services. Worldpay (UK) Limited is authorised and
> regulated by the Financial Conduct Authority for consumer credit
> activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam,
> the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence
> from and is included in the register kept by De Nederlandsche Bank, which
> registration can be consulted through www.dnb.nl. Worldpay, the logo and
> any associated brand names are trade marks of the Worldpay group.
>