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: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Wed, 18 Nov 2015 19:22:56 +0200
Message-ID: <CA+eFz_JB6VHq0PKsKSvcm9biV52NJoM7DvUHzfeYgmFbNvxbAw@mail.gmail.com>
To: Dave Longley <dlongley@digitalbazaar.com>
Cc: Web Payments <public-webpayments@w3.org>, Melvin Carvalho <melvincarvalho@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>, Anders Rundgren <anders.rundgren.net@gmail.com>
On 18 November 2015 at 16:59, Dave Longley <dlongley@digitalbazaar.com>

> On 11/18/2015 04:52 AM, Adrian Hope-Bailie wrote:
>> 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.
> This presumes the requested type is HTML. What about other cases?
> Certainly we can discuss potential optimizations of particular cases, but I
> wanted to point out that it's a very specific case.

It feels like we can divide the use cases into requests for content (maybe
include embedded resource requests?) and API-style requests that are
expecting JSON or XML or something similar in the response.

We could probably design 2 flows that catch all cases in both sets.

My point was really that we could avoid another server roundtrip

> If the format supports it, we could return the payment request in the
> response either directly (if it's a request for JSON/JSON-LD) or if it's
> HTML we could embed the payment request in the HTML using a script tag with
> "application/ld+json". But, if we're talking about an HTML page that is
> being rendered by a JavaScript-capable Web browser, then one would expect
> the website to just use the regular payment flow.
>> 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.
> Including the URL in the paymentRequest itself makes sense to me.
>> On 16 November 2015 at 23:46, Melvin Carvalho <melvincarvalho@gmail.com
>> <mailto:melvincarvalho@gmail.com>> wrote:
>>     On 16 November 2015 at 22:23, Anders Rundgren
>>     <anders.rundgren.net@gmail.com
>>     <mailto: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
> --
> Dave Longley
> Digital Bazaar, Inc.
> http://digitalbazaar.com
Received on Wednesday, 18 November 2015 17:23:31 UTC

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