Re: Checkout API spec published

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

Dave Longley
Digital Bazaar, Inc.

Received on Thursday, 11 February 2016 18:30:54 UTC