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

Is it necessary for the 402 response need to redirect the user to a new URL?
The server could respond with a 402 and the body of the response could
contain a well designed HTML document that gracefully handles older and
newer browsers.

The HTML page can provide:
1. Some human-readable content such as "The page you have requested
requires payment, to pay click here" to accomodate older browsers
2. A paymentRequest object embedded in the content in a standardised way so
that the browser knows to process it (as if it had been passed to
navigator.payments.requestPayment(...)) to provide a better experience for
newer browsers.

If the browser is capable of handling the payment request then, upon
receiving the 402 response, it will look for that request in the response
body.

It will kick off the Web Payments flow getting the user to approve the
payment and will finally get back a paymentResponse (the same object it
would have returned from the API if that was how the flow had been
initiated).

I'm not sure of the best way to pass this to the payee website though,
there are a few options. The best I can think of is that the payee provides
a URI to POST this to in the 402 response, perhaps in a special header or
in the paymentRequest object itself, and the response from the payee to
this is either the resource that was originally requested or a redirect to
that resource.


On 16 November 2015 at 23:46, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

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