Loading...
Getting Started
Markdown
How Diddo Checkout Works

Diddo is built on a fundamentally different model of commerce. Most checkout systems are session-scoped: a cart belongs to one user, lives for one session, and ceases to exist once that session ends. Diddo separates those concerns entirely.

The result: a checkout experience that can live anywhere — embedded in an app, displayed on a stadium screen, encoded in a QR code, or shared as a link — and work correctly for every single person who encounters it.


🛒 Carts vs. Checkout Sessions

In Diddo, carts and checkout sessions are distinct objects with different owners, different lifetimes, and different purposes.

The Cart: Durable, Reusable, Organization-Owned

A Diddo cart is a collection of products that belongs to your organization — not to any individual customer. Carts are created ahead of time, have no expiry, and can be used by any number of people.

Carts start as template carts. A template cart defines the products and belongs to your organization — it has no customer attached and never expires. When a customer lands on a checkout URL, Diddo automatically converts the template cart into a live cart: a short-lived copy scoped to that specific session. The template cart remains intact and reusable throughout.

This means:

  • The same cart can power hundreds of checkouts simultaneously
  • A cart is not invalidated when someone purchases from it
  • You can generate carts in advance for events, campaigns, or products without knowing who will use them

The Checkout Session: Short-Lived, Customer-Scoped

A checkout session is the ephemeral, authenticated context in which a specific customer completes a purchase. It is created fresh for every checkout — either by your platform (via a Customer Session Token (CST)) for identified customers, or automatically by Diddo on page load for anonymous ones.

💡

Checking out does not remove or invalidate the original template cart. The template cart remains available — for the same customer again, or for anyone else — indefinitely.


🔗 Shareable Checkout

Because carts are not user-owned, a Diddo checkout URL is inherently shareable. Anyone with the link can open it and complete their own independent checkout — with their own session, their own payment, and their own order.

This unlocks use cases that aren't possible in traditional commerce architectures:

  • QR codes on screens — A single QR code displayed at a stadium, on a broadcast, or at an event can be scanned by thousands of fans simultaneously. Each scan creates a fresh session. No shared state.
  • Shareable links — A checkout link for a product or bundle can be shared via social, email, or messaging. Every recipient checks out independently.
  • TV commerce — A platform surfaces product catalogs on screens to a large audience. The same cart powers every checkout in that moment.
  • Pre-built carts for campaigns — You create a cart for a product drop or event before it goes live. The link (or QR) distributes itself.

🔄 What Happens on Page Load

When a customer lands on a Diddo checkout URL, the following happens automatically:

  1. Session detection — Diddo checks for an auth_token in the URL fragment. If one is present (minted by your platform via /checkout/cst), it is used to authenticate the session as an identified customer.
  2. Guest CST minting — If no token is present, Diddo's checkout component mints a guest CST automatically. This requires no action from your platform.
  3. Live cart creation — The template cart is copied into a live cart scoped to this session. The template cart remains untouched and reusable — it can power any number of simultaneous checkouts.
  4. Checkout proceeds — The session is now authenticated and the cart is live. The customer fills in their details (or has them pre-filled if identified), and checkout completes normally.

👤 Identified vs. Guest Sessions

Both session types drive the same checkout experience. The difference is when and how customer identity enters the picture.

Identified SessionGuest Session
How it startsYour platform mints a CST via POST /checkout/cst with customer emailDiddo mints a guest CST automatically on page load
Customer identityKnown from the startCaptured at payment confirmation
Card payment formPre-filled with name, email, and addressBlank — customer fills in details
Wallet payments (Apple Pay, Google Pay)Uses device-stored info — same as guestUses device-stored info — same as identified
Returning customer recognitionYes — saved addresses and cards availableNo — identity is new to this session
Best forLogged-in users in your appQR codes, shared links, broadcast scenarios

For identified sessions, even passing just an email to /checkout/cst is enough for Diddo to look up the customer's profile and pre-fill their form. See Customer Session Token (CST) for the full guide.


🏗️ Multi-Merchant by Default

Diddo carts can contain products from multiple merchants simultaneously. When a shareable cart includes items from more than one merchant, Diddo handles the underlying merchant checkouts separately behind the scenes — the customer experiences one unified flow.

This is a core part of Diddo's architecture and applies equally to identified and guest sessions, whether the checkout is embedded, hosted, or reached via QR code.


👉

Next steps:
To create a cart, see Working with Carts.

To mint an identified CST, see Customer Session Token (CST).

To generate a QR code from a cart, see QR Code Payments.