W3C home > Mailing lists > Public > public-webpayments@w3.org > November 2015

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 16 Nov 2015 14:52:03 -0500
Message-ID: <564A33E3.1030600@digitalbazaar.com>
To: public-webpayments@w3.org
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.

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.

-- 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
Received on Monday, 16 November 2015 19:52:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:43 UTC