Re: Checkout API spec published

Hey, folks–

A few minor questions, for my own education…

It wasn't clear to me how the the relationship between product price, 
tax amount, and shipping amount are delineated or described.

* Is it expected that the English string-literals "tax" and "shipping" 
will be used? (I'm assuming not, since that's in the client-side code.)

* Is the FinancialAmount amount the total amount, including tax and 
shipping? Does that meet every payment flow and international legal 
constraint, or is there some reason to separate them (maybe for 
reporting reasons?

* In the PaymentItem dictionary, there's a boolean for shipping… should 
there also be one for tax? (Some items in the same order may be taxed 
differently, for various reasons.)

* Are tax and shipping the only items? Will there be multiple types of 
taxes, like sales or VAT tax, or is that all calculated by the merchant 
at the time, and thus irrelevant to the API.

Thanks–
Doug


On 2/7/16 10:44 PM, Manu Sporny 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
>

Received on Thursday, 11 February 2016 19:34:15 UTC