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:
- Session detection — Diddo checks for an
auth_tokenin 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. - Guest CST minting — If no token is present, Diddo's checkout component mints a guest CST automatically. This requires no action from your platform.
- 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.
- 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 Session | Guest Session | |
|---|---|---|
| How it starts | Your platform mints a CST via POST /checkout/cst with customer email | Diddo mints a guest CST automatically on page load |
| Customer identity | Known from the start | Captured at payment confirmation |
| Card payment form | Pre-filled with name, email, and address | Blank — customer fills in details |
| Wallet payments (Apple Pay, Google Pay) | Uses device-stored info — same as guest | Uses device-stored info — same as identified |
| Returning customer recognition | Yes — saved addresses and cards available | No — identity is new to this session |
| Best for | Logged-in users in your app | QR 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.
