A session represents a single deposit attempt. It tracks the full lifecycle from creation through delivery.Documentation Index
Fetch the complete documentation index at: https://docs.daimo.com/llms.txt
Use this file to discover all available pages before exploring further.
Session lifecycle
Statuses
| Status | Description |
|---|---|
requires_payment_method | Session created, waiting for the user to choose how to pay |
waiting_payment | Payment method set, waiting for the user’s deposit transaction |
processing | Deposit detected, funds are being routed to the destination |
succeeded | Funds delivered to the destination address |
bounced | Delivery failed (e.g. contract call reverted), funds returned to refund address |
expired | Session timed out before a deposit was received |
succeeded, bounced, expired. Once terminal, a session cannot change status.
Credential model
Daimo uses two types of credentials:API key
Your account-wide API key. Use it server-side only for operations that require full access:- Creating sessions
- Retrieving full session details (including
clientSecretandmetadata)
Client secret
A per-session token returned when you create a session. It grants limited access to that single session:- Setting the payment method
- Checking session status
Session object
When retrieved with an API key, the full session includes:| Field | Type | Description |
|---|---|---|
sessionId | string | Unique 32-character hex ID |
status | string | One of the statuses above |
destination | object | Where funds are delivered (see below) |
display | object | UI metadata: title, verb, optional themeCssUrl |
paymentMethod | object | null | How the user is paying (see below) |
metadata | object | null | Key-value pairs set at creation |
clientSecret | string | Per-session client credential |
createdAt | number | Unix timestamp (seconds) |
expiresAt | number | Unix timestamp (seconds) |
metadata and clientSecret are omitted (returns SessionPublicInfo).
Destination
Payment methods
To collect a deposit, you first set a payment method on the session by callingPOST /v1/sessions/{id}/paymentMethods. This transitions the session to waiting_payment and returns the information needed to complete the deposit.
Four types, depending on the source:
EVM
Deposit from any of our supported EVM chains. The response includes a single-usereceiverAddress in session.paymentMethod. Display this address so the user can send funds to it.
Tron
Deposit USDT from Tron. The response includes atron.receiverAddress, a single-use Tron address where the user sends USDT.
Solana
Deposit from Solana. The response includessolana.serializedTx, a hex-encoded serialized transaction for the wallet to sign and submit.
This preserves a one-click wallet flow on Solana by bundling actions into one signed transaction.
Fiat
Hosted fiat deposit. The user pays in local currency via one of the fiat rails enabled for your org (e.g. Interac in Canada, ACH and Apple Pay in the US, or SEPA in Europe), and Daimo delivers the stablecoin to your destination — same session lifecycle as any other payment method. The response includesfiat.hostedUrl, a URL to a Daimo-hosted page that handles identity verification and the fiat transfer. Open it in a native WebView or a new browser tab; the user returns to your app after completing the flow.
paymentMethod.fiatMethod (one of interac, ach, sepa, apple_pay) to pin the hosted flow to one rail. If omitted, the hosted page lists every fiat method enabled for the org.
The hostedUrl is returned only once from createPaymentMethod — store it on the client. It is not included when retrieving the session later.
Fiat rails are enabled per-org. To request access, contact us.
source object once the user’s deposit transaction is detected, containing chain info, token details, and the source transaction hash.
See Create Payment Method for full request/response details.
Custom theming with themeCssUrl
Pass a themeCssUrl in display when creating a session to override the default Daimo UI colors, radii, and other visual tokens. The URL should point to a CSS file that redefines any of the --daimo-* custom properties.
Example CSS file:
| Property | Description |
|---|---|
--daimo-bg | Page background |
--daimo-surface | Card / modal background |
--daimo-surface-secondary | Secondary surface for contrast |
--daimo-surface-hover | Hover state background |
--daimo-text | Primary body text |
--daimo-text-secondary | Secondary text |
--daimo-text-muted | Muted text |
--daimo-title | Title / heading text |
--daimo-accent | Primary accent color |
--daimo-success | Success state |
--daimo-success-light | Success background |
--daimo-checkmark | Checkmark / confirmation color |
--daimo-error | Error state |
--daimo-error-light | Error background |
--daimo-warning | Warning state |
--daimo-border | Border color |
--daimo-placeholder | Placeholder / inactive |
--daimo-skeleton | Loading skeleton |
--daimo-qr-bg | QR code background |
--daimo-qr-dot | QR code dot color |
--daimo-radius-sm | Small radius (default 0.5rem) |
--daimo-radius-md | Medium radius (default 0.75rem) |
--daimo-radius-lg | Large radius (default 1rem) |
--daimo-radius-xl | Extra-large radius (default 20px) |
<link> element.
Polling for status
UsePUT /v1/sessions/{id}/check with the client secret to poll for status updates after the user has paid. This is how the modal tracks deposit progress, and how custom integrations can monitor sessions from the client side.
For most integrations, the modal handles polling automatically.