Re: Checkout API spec published

Hi Manu, Dave,

Thanks for this. There was clearly a lot of work that went into it.
It's a clever approach to solving the problem that Google/Microsoft have
highlighted as a priority for them.

When combined with the revised browser API proposal from the CG it seems to
tick many of the boxes we want to cover.

I have one question which relates to a comment you made about the use of
JSON-LD on the web for semantically marking up offers and receipts. Would
it not make sense for the Extensibility section of the browser API to stand
alone in it's own document that describes the full end-to-end flow of data
from semantic markup of an offer in a search result to payment to receipt
email with semantic markup?

I can imagine at least 5 documents that we could produce on the back of
this work:

   1. Browser API specification
   A basic payments api with a simple request/response/acknowledge flow for
   a payment. Use of this primitive in other flows (besides checkout) would be
   possible (and encouraged) in future (consider p2p payments etc).
   2. Checkout API specification
   An api that allows websites to leverage the various secure mechanisms
   built into the browser to capture private/sensitive data such as shipping
   address and to link these steps together culminating in a secure payment.
   The goal is a streamlined and secure user experience.
   3. Messaging and Extensibility specification
   A document that describes the basic logical data model of the various
   messages used in both the browser and checkout APIs (i.e. take the WebIDL
   and provide simple and complex examples for different use cases) and
   provides guidance on how they may be extended using JSON-LD and examples of
   how this semantic data may be used outside of the checkout and payment to
   formulate offers and receipts.
   4. HTTP api
   A specification that describes how the payment flow might be executed
   between two entities where there is no user interface via HTTP.
   5. A Card Payment Method specification
   A specification of a basic card payment method to bootstrap the browser
   API and allow browsers to use the card details they already hold for users
   and execute card payments more securely than a traditional form submission.
   (AdrianBa was working on this already I believe).

This also begins to address some of the use cases we know are important to
merchants but are not in scope for v1.

Adrian



On 8 February 2016 at 06:05, Zach Koch <zkoch@google.com> wrote:

> Hey Manu (and Dave) -
>
> Thanks for putting this together so quickly! I'll need a couple of days to
> review everything, but will follow up in the next couple of days with
> comments and feedback, hopefully before our WG call on Thursday.
>
> Thanks,
>
> -Zach
>
>
> On Sun, Feb 7, 2016 at 7:44 PM, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> Hey folks,
>>
>> Dave Longley and I tried to see what his Checkout API proposal[1] would
>> look like applied to the Google/Microsoft spec proposal. This was mainly
>> for our own edification, but the result seemed like it might be useful
>> to the group, so we're publishing it to see what others think.
>>
>> Here's the result:
>>
>> https://wicg.github.io/web-payments-browser-api/checkout-api.html
>>
>> * The Checkout API seems to address the use cases that we heard from
>>   Zach (make the payment flow much nicer and unified for payers,
>>   make control of the flow something the browser handles, etc.)
>> * There is a nice and clean separation between the high-level
>>   Checkout API and the low-level PaymentRequest API. This follows
>>   many of the principles in the Extensible Web Manifesto that many
>>   W3C API developers are trying to adhere to these days.
>> * We were able to convert all of the APIs to a purely promise-based
>>   system (no events, no external state management), which should
>>   be much easier for developers to use and which don't have the
>>   downside of having possible race conditions.
>> * We future-proofed the shipping address collection in the event
>>   that the Verifiable Claims work generates something this
>>   API can use (there is a clear path to switch to the new model
>>   if there is benefit).
>>
>> Here's the process we followed:
>>
>> 1. We took the base Google/Microsoft Payment Request API proposal
>>    and copied the entire document into another WICG repository (to
>>    ensure there were no issues w/ IPR).
>> 2. We merged the Checkout API proposal into the PaymentRequest API.
>> 3. We then started removing the bits that were redundant wrt. the
>>    lower-level payments API, which simplified the API quite a bit.
>> 4. We were also able to entirely remove the event and state machine
>>    bits from the API, which simplified the API further.
>>
>> To be clear:
>>
>> * We are not "forking" the Google/Microsoft spec nor do we intend to
>>   maintain this as an alternate spec unless the WG decides that it
>>   likes the direction, and even in that case, we'd like AdrianB and
>>   Zach to keep editing it (with us as backup editors).
>> * This is experimental and is an attempt to harmonize all of the
>>   discussion in issues and spec proposals currently on the table.
>>
>> -- manu
>>
>> [1]https://github.com/w3c/webpayments/wiki/Checkout-API
>>
>> --
>> 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/
>>
>>
>