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: Manu Sporny <msporny@digitalbazaar.com>
Date: Wed, 18 Nov 2015 13:12:09 -0500
Message-ID: <564CBF79.2060205@digitalbazaar.com>
To: Web Payments <public-webpayments@w3.org>
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.

-- 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/
Received on Wednesday, 18 November 2015 18:12:36 UTC

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