How a purchase happens
The whole Checkout integration in one diagram: who calls whom between the browser, your server and Kustom, from POST /checkout/v3/orders to the push.
The customer never leaves your store. You build a payload describing the cart, then create an order from it. Kustom hands back a snippet you render on your page, and just before the purchase completes Kustom may call you back to validate it. Two independent things then tell you the customer paid: a browser redirect to your confirmation page, and a server-to-server push, and either can arrive alone.
Here is that sequence as the traffic between the three systems in every direct integration:
- Create the orderPOST the cart from your server. Kustom returns an order_id and an html_snippet.Your server → KustomPOST/
checkout/ your secret never leaves your serverv3/ orders Kustom → Your serverorder_id + html_snippet - Render the snippetPut the snippet on your checkout page — the customer pays inside Kustom's iframe.Your server → Customer's browserhtml_snippetCustomer's browser → Kustomthe checkout iframecard details go straight to Kustom — never through your page
- Validate optionalJust before the purchase completes, Kustom asks your server to approve it.Kustom → Your serverPOSTyour validation URLanswer 200 and the purchase completes
- Confirm and pushThe browser comes back and the push fires — read the order, acknowledge it.Kustom → Customer's browserredirect: your confirmation pageKustom → Your serverPOSTyour push URLeither can arrive first — do the same work on both, idempotentlyYour server → KustomPOSTacknowledgestops the push retries
Pay order is not the end. The order is now authorized, and the same object runs the rest of the lifecycle:
The five pages below build it in order, and each one runs live against the Kustom Playground so you can see the actual calls rather than take them on faith.
What each page answers
Section titled “What each page answers”| Page | Answers |
|---|---|
| What to send | What goes into the order payload, which fields are required and why the order lines matter beyond the total. |
| Create the order | How a payload becomes a live checkout — the request, the response and what to store from it. |
| Render Checkout snippet | How to put the snippet on the page, and keep the order behind it in sync as the cart changes. |
| Answer the callbacks | Whether you need callbacks at all, and how to answer the ones you do. |
| Confirmation & push | How you know, reliably, that the customer paid, and what to do if a push never arrives. |
Which integration model is this?
Section titled “Which integration model is this?”This guide builds the embedded checkout — Kustom Checkout rendered inline on a page you own, rather than hosted on a Kustom-served page or wrapped in a native mobile app. Nothing below applies to those two: the payload is the same, but creating, rendering and confirming the checkout are not. If either of those fits your integration better, see Integration models to compare the options, or go straight to the mobile SDK for a native app.
Fast path or full build?
Section titled “Fast path or full build?”The quickstart is 15 minutes and proves the integration works, live, against the Playground, with a working route for each step already written for you to read. This guide is what you actually ship — the full payload, the update story once a checkout is on screen, the callbacks and both routes that confirm a purchase. Run the quickstart first to see it work. Come here when you’re ready to build it for real, one page per decision you still have to make.
Related
Section titled “Related”- Order lifecycle — the statuses underneath this sequence
- Order Management — what happens after the money is authorized
This page is also available as Markdown — append .md to its URL — and is indexed in llms.txt.