Re: FPWD-ready Web Payments HTTP API and HTTP Messages specs

On 09/12/2016 03:31 PM, Adrian Hope-Bailie wrote:
>> Based on your comments, I think that there is still a disconnect on
>> the purpose of this API. We hope to resolve some of that 
>> misalignment at the upcoming face-to-face meeting
> Any hints on where we're missing each other?

Yes, based on the comments from the chairs and staff, there seems to be
this belief that the Web Payments HTTP API is for interactions between a
merchant and a PSP. I believe that's the disconnect.

The current HTTP API is meant to align w/ the capabilities of the
Browser API. That is, it's an interface between a Payment App, a Payment
Mediator, and a Merchant.

That is not to say that we couldn't add Payment App - PSP (push) and
Merchant - PSP (pull) communication in the Web Payments HTTP API, but
the group hasn't, to date, focused on that particular interaction. In
other words, we didn't feel comfortable going down that route unless the
WG wanted us to head down that (new) path. I don't expect that new path
is going to be an easy one to head down. So, I expect part of the
discussion at TPAC is going to center around this mis-alignment. See
slide #4 here:

We are currently aware of at least 77 PSPs of which only two (2!) of
them are officially participating in the group. I'll also note that we
only have around six merchant organizations (and I'm being generous).
So, if we are to try and standardize the merchant -> PSP API, we'd need
to get more of these organizations involved.

Perhaps we only need the top 5 PSPs, but in any case it's new territory
that we've tried very hard to not step into w/ the HTTP API without the
blessing of the group, and even then, we need to realize that this is a
much harder problem than the one we're trying to address with the
current Web Payments HTTP API.

There are currently 646 proprietary payment APIs in existence:

We've gone through an internal analysis and found around 200 of them to
be applicable to a merchant->PSP HTTP API. So, the question was asked if
the Web Payments HTTP API is following existing practice and given 200
APIs to look at, the answer is always going to be a very solid "it
depends". Doing the analysis alone would take months because many of
these APIs require you to sign up with the PSP to get access to the
APIs. With a sample set so diverse, and the barriers for looking at the
APIs so high, you're almost certainly going to model the API on a very
small subset of the total population.

That's why the Web Payments HTTP API attempts to mirror functionality
provided by the Payment Apps and Browser API specs for non-browser
environments. Standardizing the merchant-> PSP HTTP APIs may be far more
than the group can take on at the moment.

That said, the group could always march in knowing this and take a shot
at a simplified merchant -> PSP HTTP API based on a good basic
information + extensibility story. Taking that route will certainly lead
us down a "design by committee" route, but that doesn't always end in
tears (it just ends in tears most of the time).

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Rebalancing How the Web is Built

Received on Thursday, 15 September 2016 01:10:53 UTC