Create carts with h-api

I need to create carts for multiple customers behind the scenes (i.e., not tied to a browser session) in an SSO-style implementation, so I'm attempting to use the h-api to loop through the customers and create their carts. I will have the Foxy customer id and the items for each cart at the time of cart creation. I'm guessing I will want to store the resulting Foxy session so that later when users log in I can retrieve the appropriate cart.

Can someone give me a brief outline on how to accomplish this with the API? I've done a few things with the API, but I'm a bit confused on whether I should post to 'carts' first and then flesh out the cart info with a secondary PATCH request to the new cart or is there a way to create the cart with the customer id and items in one post?
Comments
  • brettbrett FoxyCart Team
    Hi @puremoxie.
    The basic flow is:
    1. POST to /carts to create the cart
    2. PUT to the newly created cart. You can do this with embeddable resources so you should be able to make it happen in a single request.
    3. At this point, the cart exists.

    From there, you can do two other things:
    * Create a session by POSTing to the create_session link rel. That'll return back an fcsid that you can use with frontend (not backend API) /cart and /checkout for SSO.
    * Attach a customer. Note that this _only_ is useful if you're then going to attempt to charge the existing customer's saved CC# via the API. (ie. No front-end interaction for the customer at all.)
    * Also note that, at this point, you can't attach shipping to a cart resource via the API. You have to create a session and go to the api_json frontend to get rates and attach the appropriate rate to the cart. (We'll be improving that in the future, but for now it's just a little awkward, but doable.)

    All that said, can you clarify your use case? Generally you wouldn't want to create a cart before it's actually needed. In other words, I'd suggest creating the cart dynamically on login, rather than looping through all customers and creating carts for each. The key here is that a cart to be used in the front-end by a customer is just a cart. It doesn't belong to a particular user. At least, not as far as Foxy is concerned. And we do clean up old carts that weren't completed (ie. that weren't paid for). So relying on a cart to exist that may have been created in the past isn't generally the safest option.

    Does that help, for now at least?
  • Yes, thank you, that definitely gets me on the right track.

    The use case is for an auction site, where registered users can bid on and "win" items and then pay via the Foxy checkout process. Since they may not be on the site when the auction ends and they win, I want to create the cart for them behind the scenes. Although, as you mention, I have debated doing it at their next login, and may still go that route. The one thing I was aiming for though was to have their email notification that they won have a direct link to their checkout.
  • brettbrett FoxyCart Team
    Hi @puremoxie.
    Thanks for the info. If you haven't already thought about it from this angle, I'd perhaps approach it this way:
    1. Create the cart for the winner, then…
    2. If the winner has purchased before and already has saved payment info in Foxy, go ahead and use the API to attempt to charge their card.
    2.a. If there's an error, continue to step 3.
    3. If the winner hasn't purchased before or doesn't have a saved card, send them the link to the cart to complete the checkout.

    Note also that you can set the cart session lifespan to 14 days, so you could actually create the cart, create the session, then send them a link to their session. It wouldn't last forever, but it'd probably be easier than sending them a link to your site that then creates a session dynamically (though I guess that wouldn't be too difficult, if you're already doing everything else).

    Neat use case, though. Let us know if we can help.
Sign In or Register to comment.