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

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


>
> Anders
>
>
>> -- manu
>>
>>
>
>