- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 18 Nov 2015 13:12:09 -0500
- 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