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

Thanks for the clarity. There is nothing new here but it helps me at least
understand some of the design motivations and reassure me I'm not crazy (a
little sure but not totally nuts).

I think there is a big disconnect here between design motivations and use
cases or there are use cases here that I am not thinking of.

The design motivations are to replicate what we are doing in the browser
API via HTTP but what is the use case for this? The architecture of the
browser API is centered around the browser as a mediator on behalf of a
human-user who must make decisions during the process like selecting a
payment app. Where does a mediator fit in when there is no UI via a
browser? What payments are conducted in this manner today?

I see use cases like content payments where a user requests a resource,
gets back a 402, and the browser responds by using a registered payment app
to process the payment request and ultimately respond via HTTP. But why
does this need HTTP APIs to register or manage payment apps?

For the IoT use cases, why would a device that is making a payment have
multiple payment apps and payment mediator components? That seems like a
massive over-complication for a system where there is no user interaction?

The predominant use case for HTTP APIs in payments is between the payer and
payee directly (where the payee may be represented by some payment
app/wallet and the payee may also be represented by their PSP). There is no
"mediator" role.

So, as I said in my comments on the CfC, while I think we need to do this
work I don't think the current spec reflects a clear picture of what is out
there today in terms of HTTP APIs that can be "standardized" nor does it
represent a design that appears to accommodate the many use cases (like
IoT) for which this API is purported to address.

Looking forward to the TPAC discussion


On 15 September 2016 at 03:10, Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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:
>
> https://docs.google.com/presentation/d/1MobW3X6vH0MP9SpTE37tDlOnM5hgx
> 3-DgQT1xDWs40U/edit#slide=id.g115581d66b_0_139
>
> 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:
>
> http://www.programmableweb.com/category/payments
>
> 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
> http://manu.sporny.org/2016/rebalancing/
>
>