- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Thu, 11 Feb 2016 13:30:26 -0500
- To: Zach Koch <zkoch@google.com>, Adrian Hope-Bailie <adrian@hopebailie.com>
- Cc: Rouslan Solomakhin <rouslan@google.com>, Ian Jacobs <ij@w3.org>, Payments WG <public-payments-wg@w3.org>, Manu Sporny <msporny@digitalbazaar.com>
On 02/11/2016 06:19 AM, Zach Koch wrote: > Hi all - > > I've been mulling this over the last week, and I've posted some > thoughts below. Hopefully we can talk more about this on today's > call: > > * I don't think we should break this out into two separate APIs. I > would still prefer a single API that developers can use in a > consistent way to get the information necessary to finalize a > transaction (i.e. payment credential, potentially a shipping > address). We don't know if the Checkout API we come up with is going to be the best way to do things. Over time, people have found that a good approach to that problem is to standardize the low-level bits that you need to add to the Web Platform in order build higher-level APIs, and then let people experiment with JS on top. We might come up with a Checkout API that simply doesn't work the right way or that accidentally codifies or increases, for example, certain reasons for cart abandonment. I'm fine with us forging ahead and creating a Checkout API and experience that we think will help, but it is a bit cart before the horse. At the same time, clearly sites have been wrestling with this for a long time and need "a way" to forge forward because they've shown they want help and it's not happening on their own. I'm supportive of developing a standard for people to work with in those cases. Maybe it will work, maybe it won't, but at least put it out there as a common way forward. Keeping all that mind, let's protect ourselves and ensure that we're also putting out a low-level API that provides the minimum bits necessary to build Web payments into the Web Platform; we need that low-level API. The same could be said for low-level shipping address APIs and similar, but we're pushing those off because there's a potential for future work by other groups to touch on that. > > I also would prefer an event-based mechanism for thinks like > shippingOptionChange and addressChange. It just feels cleaner. I like the concept of being notified of what changed. The problem is that "you need to respond to it and transfer control back". I tried find a middle ground where the merchant site can request various things at various times and expect to receive that information when the Promise resolves. -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Thursday, 11 February 2016 18:30:54 UTC