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

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.

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
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Wednesday, 18 November 2015 15:00:18 UTC