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

On 09/15/2016 04:58 AM, Adrian Hope-Bailie wrote:
> 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.

Let me try to point out the use cases my company is interested in, maybe
that'll help.

> The design motivations are to replicate what we are doing in the 
> browser API via HTTP but what is the use case for this?

I tried to detail the generic use case in the blog post:

http://manu.sporny.org/2016/yes-to-http-api/

"""
A piece of software (that is not a web browser) operating on behalf of a
payer attempts to access a service on a website that requires payment.
The payee software provides a payment request to the payer software. The
payment request is processed and access is granted to the service.
"""

I'm hoping the one that will resonate the most with folks is the regular
bill payment where the total fluctuates. Think gas, electricity, fuel
oil, cloud service, etc. In this scenario, you know who you have to pay,
you know you have to pay monthly, but you don't know the total (and that
makes it impossible to setup via your banks bill payment application).
You end up having to share your ACH or card information with the
merchant (which is bad for a variety of reasons). The most prominent one
being that when your card or bank account information changes, automatic
payments fail and you have to set everything back up again.

So, this is a case for the HTTP API. If your "subscription application"
(aka mediator) had the ability to setup automated payments, you'd have
to give it (or setup) the billing endpoint (the thing that generates the
402 / Payment Request), tell it how much you're willing to spend per
month on that service provider, and that's pretty much it. The
subscription application may then use whatever payment mechanism
available to it to make payment that the merchant takes. When cards or
account expire, there is no new setup necessary, payments continue to be
made until you choose to stop payments (or the service provider
determines that you're no longer a customer).

It's these sorts of use cases that are top of mind and are aligned w/
the design the group is currently pursuing. I think the IoT use cases
are a bit of a red herring at this point.

> 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?

The mediator in the HTTP API is typically a "smart payment agent", like
a piece of software running in the cloud that manages your subscriptions
to services.

> What payments are conducted in this manner today?

There are two parts to the way payments are conducted today:

1. Getting the information from the customer to the merchant.
2. Getting the payment instruction from the merchant to the PSP.

The group is currently focused on #1. The browser API is focused on this
as is the HTTP API.

We haven't touched #2 as a group, and I suggest we stay away from it.

> 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?

Hopefully the automated subscription payment use case above makes this
clear.

> For the IoT use cases, why would a device that is making a payment 
> have multiple payment apps and payment mediator components?

Simple ones wouldn't and might combine the payment mediator and app.
Complex ones (like a car) would probably support multiple payment apps.

> That seems like a massive over-complication for a system where there 
> is no user interaction?

The design provides flexibility and is orthogonal to the way we're doing
things via the Browser API. If you're making an argument to deviate from
the ecosystem we've built via the Browser API and reduce flexibility,
then we're going to have to discuss the reasoning for restraining the
ecosystem. Happy to do that, but wondering what the rationale for
deviating is.

> 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.

I think you mean "where the payer may be represented"?

I wouldn't say there is a "predominant" use case for the HTTP API just
like there isn't a predominant one for the Browser API. There are a set
of use cases and we're trying to use the simplest design and
implementation to achieve as many of those use cases as possible.

I also hesitate to remove the mediator from the design. What you
describe above could just as easily be achieved by combining the payment
app and mediator roles (and that would be a perfectly reasonable thing
to do). However, there are use cases that we can see that require the
mediator to exist. For example, a subscription application that is not a
payment app, but needs to use payment apps to generate payment responses
to payment requests.

> 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.

If it doesn't accommodate certain use cases that you think are
important, it would help for you to clearly articulate the use case and
we'd be happy to apply the current design to the use case and see if we
can achieve the use case in question.

-- 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/

Received on Thursday, 15 September 2016 13:56:56 UTC