Re: How would 402 Payment Required work? (was Re: wired - Coinbase Is Out to Build Payments Right Into Browsers)

On 16 November 2015 at 20:52, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 11/16/2015 04:55 AM, Anders Rundgren wrote:
> > On 2015-11-16 10:35, Adrian Hope-Bailie wrote:
> >> This article doesn't provide much detail on how they think a 402
> >> response and the subsequent flow would work.
> >
> > Has anybody to date provided a detailed description on how they
> > think that a 402-based micro-payment system would work?
>
> There have been proposals, here's something we've been proposing for 7+
> years now:
>
> Customer hits URL that requires payment, response is "402" with
> "Location:" HTTP header set to the start of a payment process.
>
> At this point, one of at least two things could happen:
>
> The browser-based flow:
>
> 1. The browser would re-direct to the page in the Location header and
>    would kick up a human-readable page that would hook into the
>    Web Payments Browser API. Effectively, the page would say
>    "Do you want to buy this for $X.XX?", if the person clicks the
>    button, it would launch into the Web Payments API flow[1].
>

Need to work out this mechanism, but I think that is along the right
lines.  It's important that the request headers can be tied to the resource
as part of an audit trail and for discovery.

One other related proposal emerging is :
https://github.com/dret/I-D/tree/master/http-problem-rdf

But I like your idea.

Question 1:  What about a "payment" header which gives the client a little
more of an idea of what it's going to.  Location is just fine, but relies
on the 402 being there.  Payment can be used with any return 4xx code,
which may be easier to implement with existing systems.

One thing im cautious of is having different meta data for a resource based
on the return code.  That sounds like an audit nightmare.


> 2. The payment request would be sent to a payment processor, processed
>    (payment made), and then returned via the Promise-based API to the
>    merchant, thus completing the flow.
>

Question 2: how would the payment URI know two key factors:

- Which URI you are accessing
- (As help) who owns that resource

This helps with the lookup of terms etc.  A typical idea may be to use
params in the query string.

I've implemented most of this but not the promises based API.  That sounds
interesting.  Im sure I'll need this in future, but can probably get by
without to start with the proof of concept.


>
> HTTP-based flow:
>
> 1. The HTTP client would request a machine-readable payment request
>    from the URL specified via the Location header.
> 2. The payment request would be taken somewhere else to be fulfilled
>    (automatically, based on the HTTP clients configuration). The
>    payment request would include a "payment request acknowledged
>    callback URL".
> 3. The payment request acknowledgement would be sent to the
>    "payment request acknowledged callback URL". The payment would be
>    noted by the server, appropriate state/cookies set, and the
>    client would be redirected to the item purchased.
>

Sounds quite similar to the first one.  I'd need to understand more.

But I think in principle how I've implemented it and how you want to do it
are the same.


>
> The hard part is what the messages look like and how they're processed
> via both the browser and HTTP in a way that works not only for credit
> cards, but ACH, Boleto, Bitcoin, Ripple, Ethereum, etc.
>

I've more or less coded this up.  I use .well-known/payment as a catch all
tool until the follow your nose becomes more commonplace.

I'd be happy to work with interested parties to turn the prototype into
production quality, and create a spec around it.  Estimated time frame
about 1 month of work ... but I'm working on about 10 different things, so
6 months is probably more suitable.


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