- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 19 Jun 2016 21:27:47 -0400
- To: public-payments-wg@w3.org
On 05/05/2016 01:15 PM, Jason Normore wrote: > Manu, here’s some high level feedback, I apologize last minute > review. Hey Jason, apologies for the delay in getting back to you on the HTTP API. As you know, the focus has been on the Browser API for the last couple of months. That said, I'm getting back into the HTTP API as the Browser API seems to be stabilizing and I'm trying to align the two as much as possible. > I'm a little concerned that using there 402 response code is > limiting the scope of where this could be used. It seems that 402 is > great for a pay-wall experience: no access to this resource unless > you pay, all or nothing. This is also a valid, and even common, use > case for browser based commerce applications but not the only one, or > at least not the one that allows for the best experience. The previous spec made the mistake of making it seem like 402 was required. It's optional. It's specifically designed for paywall experiences, but that's not the only way one can get a Payment Instruction. This has been changed in the latest HTTP API spec diagram here (note the "optional first step" dashed box): https://w3c.github.io/webpayments-http-api/#payment-flow-overview > When you break it down, merchants want to say "something here is for > sale", then provide product and pricing information that the customer > can use to determine whether they want to purchase or not, they > purchase and the product is delivered in whatever mechanism is > appropriate (physical shipment, digital delivery). The browser spec > doesn’t use 402 right now because it doesn’t need to in order to > provide the best experience, is this really the best approach for the > HTTP API given that it’s meant to solve the same problem? It's an option that exists for the HTTP API that isn't there for the Browser API (yet). It's a way for a site to say: "Oh, you want to access this thing, and you can totally do that, but you have to pay and here are the details of that payment". The Web Payments Community Group specs have also, for a very long time, had the concept of a merchant digitally signing and publishing an offer of sale on any website. Those offers are then picked up by search engines which could then forward them to people, aggregate them, etc. So, instead of a customer knowing which site to go to (and taking the 402 route), they'd do a search instead. For example "buy socks" and get a list of digitally signed offers back. They'd select the one they want and then hand off the offer (which could be a Payment Instruction) to the Web Payments HTTP API (their smart buying agent). I'm not saying all the details for this are worked out, just outlining another way a Payment Instruction (request) could get to the HTTP API. Do you think that there is a better way, other than that blue box around the first step, of showing that the above is possible via the HTTP API? > Although today most online commerce is in browsers, this may not be > the case tomorrow, it's important for us to provide this > standardized experience to connect merchants, customers, and PSPs > across any platform or medium. In terms of priority, the majority of > online commerce happens in browsers today so this would fall to the > top of the list for us but the HTTP API is important for the future > so we'd like to see the WG focus on this in parallel to see it > actually built but also to ensure we have as much common components > as possible, as common language for facilitating the checkout > experience with different mechanisms for transporting the data would > ensure adoption. +1 :) -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. JSON-LD Best Practice: Context Caching https://manu.sporny.org/2016/json-ld-context-caching/
Received on Monday, 20 June 2016 01:28:14 UTC