# 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:

1. **[Create the order](/checkout/integrate/create-order/)** — POST the cart from your server. Kustom returns an order_id and an html_snippet.
   - Your server → Kustom: POST `/checkout/v3/orders` (your secret never leaves your server)
   - Kustom → Your server (response): order_id + html_snippet
2. **[Render the snippet](/checkout/integrate/render-checkout-snippet/)** — Put the snippet on your checkout page — the customer pays inside Kustom's iframe.
   - Your server → Customer's browser: html_snippet
   - Customer's browser → Kustom: the checkout iframe (card details go straight to Kustom — never through your page)
3. **[Validate](/checkout/integrate/validation-callback/)** (optional) — Just before the purchase completes, Kustom asks your server to approve it.
   - Kustom → Your server: POST `your validation URL` (answer 200 and the purchase completes)
4. **[Confirm and push](/checkout/integrate/confirmation-and-push/)** — The browser comes back and the push fires — read the order, acknowledge it.
   - Kustom → Customer's browser: redirect: your confirmation page
   - Kustom → Your server: POST `your push URL` (either can arrive first — do the same work on both, idempotently)
   - Your server → Kustom: POST `acknowledge` (stops the push retries)

Pay order is not the end. The order is now authorized, and the same object runs the rest of the lifecycle:

- [Order Management](/order-management/) (once authorized) — Capture as you ship, refund a return, cancel what you cannot fulfill.
- [Finance](/finance/) (once settled) — Payout schedules, and the settlement reports that reconcile them.

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

| Page | Answers |
|---|---|
| [What to send](/checkout/integrate/the-order/) | What goes into the order payload, which fields are required and why the order lines matter beyond the total. |
| [Create the order](/checkout/integrate/create-order/) | How a payload becomes a live checkout — the request, the response and what to store from it. |
| [Render Checkout snippet](/checkout/integrate/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](/checkout/integrate/validation-callback/) | Whether you need callbacks at all, and how to answer the ones you do. |
| [Confirmation & push](/checkout/integrate/confirmation-and-push/) | How you know, reliably, that the customer paid, and what to do if a push never arrives. |

## 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](/checkout/#integration-models) to compare the options, or go
straight to the [mobile SDK](/checkout/mobile-sdk/) for a native app.

## Fast path or full build?

The [quickstart](/checkout/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

- [Order lifecycle](/basics/order-lifecycle/) — the statuses underneath this sequence
- [Order Management](/order-management/) — what happens after the money is authorized