Re: Checkout API spec published

Hi Manu,

I've looked over the Checkout spec. It's a great start. There's one issue
to resolve.

The browser can signal the merchant only by resolving the promise that
calls finishCheckout() in your examples. In the course of a checkout, it's
conceivable that the user selects shipping option 1, then shipping option
2, then shipping option 1 again. Your examples show recalculations of the
line items with a call to checkout.send('paymentItem',
checkoutDetails.items) when this happens. The checkout.send() function is
synchronous. After calling it, the code steps down to the line that
requests the payment. However, the user has not finished selection their
payment options yet.

I can see 2 ways to resolve this issue from the top of my head:


   1. checkoutDetails should have a "finished" boolean field. This is set
   to false when user changes shipping options. It is set to true when the
   user clicks "Buy". The merchant has to check this field.

   if (!checkoutDetails.finished)
     checkout.continue().then(finishCheckout);
   else
     checkout.finish(...);

   2. Fire events instead of resolving a promise when the user selects a
   shipping option. Usage of your API would change slightly.

   var checkout = new Checkout();
   checkout
       .onEvent('shippingOptionChange', recalculateLineItems)
       .show()
       .then(finishCheckout);

   // Returns line items with updated price/tax/etc based on the options
   that the user has selected in checkoutDetails.
   function recalculateLineItems(checkoutDetails) {
       ...
   }

   // Requests the payment from the browser.
   function finishCheckout(checkoutDetails) {
     checkout.finish(...);
   }


I prefer option 2, because it's harder for the merchant to accidently
charge you before you've finished selecting your payment and shipping
options. What do you think?

Cheers,
Rouslan

On Tue, Feb 9, 2016 at 1:02 PM Ian Jacobs <ij@w3.org> wrote:

>
> > On Feb 9, 2016, at 12:34 PM, Dave Longley <dlongley@digitalbazaar.com>
> wrote:
> >
> > On 02/09/2016 12:11 PM, Ian Jacobs wrote:
> >> [snip]
> >>
> >> My suggestion is that @context be explicit in the data that is passed
> >> to the API (and thus HTTP info not necessary).
> >>
> >> I am hearing you say you have use cases where the @context cannot be
> >> stated explicitly. Can you say more about those use cases?
>
> [snipping your reply]
>
> Dave,
>
> Thanks for the productive phone call today. It helped me understand the
> JSON-LD
> landscape and I think we ended up on the same page. I look forward to the
> next proposal!
>
> Ian
>
> --
> Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
> Tel:                       +1 718 260 9447
>
>
>
>