- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Wed, 18 Nov 2015 19:22:56 +0200
- 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>
- Message-ID: <CA+eFz_JB6VHq0PKsKSvcm9biV52NJoM7DvUHzfeYgmFbNvxbAw@mail.gmail.com>
On 18 November 2015 at 16:59, Dave Longley <dlongley@digitalbazaar.com> wrote: > 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 potentially. > 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 17:23:31 UTC