Order Lifecycle

The canonical definition of order statuses, transitions, and refund semantics. This is the only page that defines the status tables — every other page links here.

Status reference

v2 REST responses return status as the display string (e.g. "UNCONFIRMED PAYMENT"). The numeric codes exist in v1 payloads and are accepted by the list endpoint's status filter (which takes the integer code or the exact status name).

Code	Status	Description
11	INITIAL	Order created, awaiting deposit
12	UNCONFIRMED PAYMENT	Deposit detected but not yet confirmed
13	PAID	Deposit confirmed
14	PRE-RELEASE	Withdrawal transaction being created
15	RELEASED	Withdrawal transaction broadcast
16	COMPLETED	Withdrawal transaction confirmed — terminal
0	CANCELED	Deposit not received and the order expired — terminal
9	PENDING KYC	Held for additional due diligence
6	INITIATED REFUND	Refund process started
7	REFUND FAILED	Refund attempt failed (will be retried)
8	REFUNDED	Deposit returned to the refund address — terminal

There is no EXPIRED status

Expiry is not a distinct status. An unpaid order past its payment deadline transitions to CANCELED. See countdown logic for how deadlines are derived.

Terminal vs active

• Terminal (stop polling): COMPLETED, CANCELED, REFUNDED
• Active (keep polling): everything else, including PENDING KYC, INITIATED REFUND, and REFUND FAILED
• Unknown values: treat as active — new statuses may be introduced.

Standard (CeFi) flows

✅ Success:

INITIAL → UNCONFIRMED PAYMENT → PAID → PRE-RELEASE → RELEASED → COMPLETED

❌ Unpaid / expired:

INITIAL → CANCELED

🔍 KYC review, passed:

INITIAL → UNCONFIRMED PAYMENT → PENDING KYC → PAID → PRE-RELEASE → RELEASED → COMPLETED

🔍 KYC review, failed:

INITIAL → UNCONFIRMED PAYMENT → PENDING KYC → INITIATED REFUND → REFUNDED

🔄 Refund retry:

INITIATED REFUND → REFUND FAILED → INITIATED REFUND → REFUNDED

DeFi flows

DeFi orders use a subset of the state machine — there is no UNCONFIRMED PAYMENT, PAID, or PENDING KYC stage:

INITIAL → PRE-RELEASE → RELEASED → COMPLETED
or
INITIAL → RELEASED → COMPLETED

Failed or expired DeFi orders follow the refund path:

INITIAL / PRE-RELEASE / CANCELED → INITIATED REFUND → REFUNDED

RELEASED means the withdrawal was broadcast; COMPLETED is set once it reaches the destination currency's confirmation requirement (see min_confirmations on GET /currency/).

Transaction statuses

Deposits and withdrawals are tracked internally as transactions with their own state machine. v2 order responses expose only the resulting hashes (deposit_transaction, withdraw_transaction), but transaction state drives the order transitions, and the numeric codes appear in v1 payloads:

Code	Status	Applies to	Description
1	INITIAL	withdrawal	Created
4	STAGED	withdrawal	Staged for signing
7	AUDITED	withdrawal	Passed audit
10	UNCONFIRMED	both	Broadcast, awaiting confirmations (deposits start here)
13	CONFIRMED	both	Confirmed on-chain
0	CANCELED	withdrawal	Canceled
-1	AUDIT_FAILED	withdrawal	Failed audit
-5	DROPPED	both	Dropped from mempool
-10	FAILED	both	Failed

How transaction state maps to order state:

• deposit UNCONFIRMED → CONFIRMED ⇒ order UNCONFIRMED PAYMENT → PAID
• withdrawal UNCONFIRMED → CONFIRMED ⇒ order RELEASED → COMPLETED

Confirmation-count increases alone do not change transaction status.

Refund flow & outcomes

REFUNDED is a terminal outcome of a swap that could not be completed — the user's deposit was returned instead of the swapped funds. Treat it as a distinct end state in your UI, not a success variant.

• Refunds go to the order's refund_address, with refund_address_extra_id attached for chains that need a memo/tag — which is why collecting both at creation matters (Create Order).
• REFUND FAILED is transient: refunds are retried until they succeed (INITIATED REFUND → REFUND FAILED → INITIATED REFUND → REFUNDED).
• Orders can enter the refund path from KYC failure, DeFi execution failure, or expiry after partial payment — the trigger is not exposed as a field; contact support with the unique_reference when a user needs specifics.

Next steps

• Order Tracking — polling cadence built on these states
• Webhooks — push notifications on status change
• Payment UI patterns — mapping statuses to user-facing stages