The /checkout/cst endpoint lets you mint a Customer Session Token (CST) — a short-lived JWT that authenticates your customer through their checkout experience.

Minting a CST is recommended whenever you know who your customer is. Passing even just an email address gives Diddo enough to create a personalized checkout experience for that customer — pre-filling their card payment form and surfacing their saved details. The more you share, the less your customers have to type.

For flows where no customer identity is available — QR codes on screens, shared links, broadcast commerce — Diddo handles CST generation automatically on page load. No action required on your end.

📘 Full request/response schemas are available in the API Reference.

🔒 How It Works

A CST is scoped to a single customer session and expires after 24 hours. It links your cart to a verified customer identity, which Diddo uses to authenticate the session on the checkout side.

You mint a CST by sending a POST request to /checkout/cst with your Diddo API key in the Authorization header. The token is then passed to the Diddo checkout page, where it scopes the entire session to that customer.

✨ Why Minting a CST Unlocks a Better Experience

When you mint a CST with a customer's email, Diddo looks up that customer's existing record. If they've checked out through any Diddo-powered platform before, their details are already on file.

A CST minted with customer identity unlocks:

• Pre-filled card payment form — when a customer pays by card, their name, email, phone, and address are populated automatically. Returning customers don't re-enter anything.
• Saved address selection — if the customer has checked out via card before, Diddo surfaces their saved addresses for one-tap selection.
• Saved cards on file — returning customers can reuse cards from previous checkouts, making card payment a single confirmation.
• Personalized session — the checkout page is scoped to this customer from the moment it loads. No anonymous hand-off at payment time.

Note that wallet payments (Apple Pay, Google Pay) always use device-stored information — those wallets manage their own identity and address data independently. The pre-fill benefit applies specifically to the card payment path.

The difference in conversion between a blank card form and a pre-filled one is significant. Minting a CST is the single highest-leverage thing you can do as a platform.

🚀 Endpoint

POST /checkout/cst — Mint a Customer Session Token

🧭 Request Examples

Recommended: Pass Customer Identity

If you have customer data available (a logged-in or returning customer), pass it in the request body. At minimum, pass email — Diddo will use it to look up the customer's profile and pre-fill their checkout form:

json

JavaScript implementation:

javascript

All fields beyond email are optional — pass only what you have. Each call to /checkout/cst also keeps Diddo's customer record in sync: if a returning customer has updated their address in your platform, passing it here will update their Diddo profile automatically.

Guest Checkout — Handled Automatically

For flows where you don't have a customer identity up front — QR codes, shareable checkout links, or any broadcast commerce scenario — you don't need to mint a CST at all.

Diddo's checkout page detects the absence of an auth_token in the URL and automatically mints a guest CST on page load. The session is kept anonymous until payment confirmation, at which point the customer's identity is captured from their wallet or payment details and a customer record is created or matched.

This means a single cart link or QR code can be scanned and completed by any number of people, each receiving their own isolated session. No shared state, no stale tokens, no action required from your side.

💡

This is the foundation of Diddo's shareable checkout model. See How Diddo Checkout Works for the full picture on template carts, live carts, and how checkout sessions are scoped.

📦 Response

The endpoint returns a single field containing your CST:

json

Store this token securely — you'll need it in the next step to initiate checkout.

⚠️

You must pass your DIDDO_API_KEY in the Authorization header as a Bearer token. Without it, you will receive a 401 Unauthorized response.

👉

Ready to send your customer to checkout? See Hosted Checkout Flow for hosted redirect and WebView integration, or Checkout SDK to embed checkout directly in your web app.