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

On 18 November 2015 at 19:12, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 11/16/2015 03:53 PM, Melvin Carvalho wrote:
> > But I like your idea.
>
> It's in spec form here:
>
> http://web-payments.github.io/web-payments-http-api/
>
> > Question 1:  What about a "payment" header which gives the client a
> > little more of an idea of what it's going to.  Location is just
> > fine, but relies on the 402 being there.  Payment can be used with
> > any return 4xx code, which may be easier to implement with existing
> > systems.
>
> Good point, the spec above is a bit schizophrenic about this point right
> now. Could you log it as an issue against the spec above?
>
> https://github.com/web-payments/web-payments-http-api/issues
>
> I noted your comment here:
>
> http://web-payments.github.io/web-payments-http-api/#issue-1
>
> but it would be good to have an issue on it.
>
> > One thing im cautious of is having different meta data for a
> > resource based on the return code.  That sounds like an audit
> > nightmare.
>
> Yeah, that should be an issue as well. Here's what it would look like in
> your nightmare scenario here:
>
>
> http://web-payments.github.io/web-payments-http-api/#processing-a-payment-request
>
> > Question 2: how would the payment URI know two key factors:
> >
> > - Which URI you are accessing
>
> You could:
>
> 1. Use a "Referer" header.
> 2. Put the 402 response w/ payment request on the resource itself.
> 3. Encode in the query string.
> 4. Encode in an HTTP header.
>
> > I've implemented most of this but not the promises based API.  That
> > sounds interesting.  Im sure I'll need this in future, but can
> > probably get by without to start with the proof of concept.
>
> Keep in mind that the 402 flow will probably be for automatic processing
> (machines), whereas the Promises-based flow is meant for interactive
> scenarios (people using a device to execute a payment).
>
> I don't think it's a good idea to mix the two as, while the messages are
> the same, the programmatic interfaces are different.
>
> > I'd be happy to work with interested parties to turn the prototype
> > into production quality, and create a spec around it.  Estimated time
> > frame about 1 month of work ... but I'm working on about 10 different
> > things, so 6 months is probably more suitable.
>
> Spec is above, please start logging issues. Another editor on it would
> be great.
>

Thanks!  It's on my todo list ...


>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Web Payments: The Architect, the Sage, and the Moral Voice
> https://manu.sporny.org/2015/payments-collaboration/
>
>