- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Wed, 18 Nov 2015 09:59:53 -0500
- To: Adrian Hope-Bailie <adrian@hopebailie.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 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