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

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

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Mon, 16 Nov 2015 22:46:50 +0100
Message-ID: <CAKaEYhKe2wjnLt=cNfyApSN_DQXdmZgioirzyUcFUqSCzq0Jdg@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, Web Payments <public-webpayments@w3.org>
On 16 November 2015 at 22:23, Anders Rundgren <anders.rundgren.net@gmail.com
> wrote:

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

My system uses xsd : decimal, so it could easily handle 1 millionth of a

> Anders
>> -- manu
Received on Monday, 16 November 2015 21:47:19 UTC

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