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

On 2015-11-16 20:52, Manu Sporny 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].
> 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.

I still find this strange.  If the page pointed to by Location is an ordinary
page it seems it would be possible to do background payments without the user knowing.
But I may be wrong. I probably need both the code and a state-diagram to be sure.

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

For me 402 could be as Adrian points out in his video, a way to eliminate
subscriptions and associated identification of the user.  This requires
a payment system that is designed for 10c-transactions which at least
excludes credit cards.

Anders

>
> -- manu
>

Received on Monday, 16 November 2015 21:23:51 UTC