Statuses
Every resource exposes an observable lifecycle state so you always know where a payment stands. Branch on these states in your integration — and write your code to tolerate states being added over time.
Order, deposit, and withdrawal statuses are PascalCase — note Canceled with one l — and KYC/KYB states are UPPERCASE. The API reference is the authoritative source for the current set of states. New states may appear as corridors and rails evolve, so treat any value you don't recognize as non-terminal and keep polling (or wait for the next webhook) rather than failing.
Order statuses
An order moves from creation through collection, exchange, and payout to a terminal outcome. The API reports this progress with a small, stable set of statuses — the many internal processing steps are collapsed into Processing, so you integrate against six values rather than the internal state machine. Pending, Processing, and Reviewing are transient; Success, Failed, and Canceled are terminal.
| Status | Meaning | Terminal |
|---|---|---|
Pending | The order is created and waiting for the origin funds to arrive. | No |
Processing | Funds have arrived and the order is being worked through the corridor — the internal collection, exchange, and payout steps are reported as Processing (a few transient internal states report as Pending). | No |
Reviewing | The order is held for compliance review. | No |
Success | Funds have been paid out to the destination. Nothing further will change. | Yes |
Failed | The order could not be completed. Any collected funds are returned per the corridor's rules. | Yes |
Canceled | The order was canceled before payout. It will not progress further. | Yes |
When filtering orders with GET /v1/orders?status=…, use these six values. For backward compatibility the filter also still accepts the older, more granular internal states (e.g. Exchanging, Withdrawn), but they are never returned when you read an order (detail or list) — a read order always carries one of the six statuses above.
Deposit statuses
A deposit tracks incoming origin funds against an order. It is Received once the money is confirmed and available to settle the order, and Success once fully processed.
| Status | Meaning | Terminal |
|---|---|---|
Pending | A deposit is expected but the funds have not yet arrived on the rail. | No |
Processing | Funds have arrived and are being confirmed and reconciled. | No |
Received | Funds are confirmed and available to settle the order. | No |
Reviewing | The deposit is held for compliance review. | No |
PendingCancel | A cancellation has been requested and is being processed. | No |
Success | The deposit is fully processed. Nothing further will change. | Yes |
Failed | The deposit could not be processed — for example it was returned or reversed on the rail. | Yes |
Canceled | The deposit was canceled. It will not progress further. | Yes |
Withdrawal statuses
A withdrawal tracks the outbound payout leg to the destination. It ends in Success, Failed, Rejected, or Canceled.
| Status | Meaning | Terminal |
|---|---|---|
Pending | The withdrawal is accepted and queued for processing. | No |
Pending2FA | Waiting for two-factor approval. Approving via POST /v1/withdrawals/approve moves it to Pending. | No |
PendingVerification | Waiting for verification to complete before processing. | No |
Compliance | The withdrawal is held for compliance checks. | No |
Review | The withdrawal is flagged for manual review. | No |
Reviewing | The withdrawal is under review. | No |
Accepted | The withdrawal has been accepted for processing. | No |
Approved | The withdrawal has been approved and is proceeding to payout. | No |
PendingWithdrawal | The payout is queued on the destination rail. | No |
Processing | The payout has been submitted to the destination rail and is in flight. | No |
PendingCancel | A cancellation has been requested and is being processed. | No |
Success | Funds have been delivered to the destination. Nothing further will change. | Yes |
Failed | The payout could not be delivered — for example the destination was rejected by the rail. | Yes |
Rejected | The withdrawal was rejected during review or compliance checks. | Yes |
Canceled | The withdrawal was canceled before delivery. It will not progress further. | Yes |
KYC / KYB statuses
Identity verification for an entity uses UPPERCASE states. Poll the entity or subscribe to webhooks to react when it becomes APPROVED or REJECTED.
| Status | Meaning | Terminal |
|---|---|---|
PENDING | Verification has been requested and is awaiting the required information. | No |
IN_PROGRESS | The entity is completing the verification flow. | No |
REVIEWING | The submitted information is being assessed. | No |
APPROVED | The entity is verified and can transact. | Yes |
REJECTED | Verification did not pass. Follow up through your account contact to resolve. | Yes |
NOT_AVAILABLE | No verification is available for this entity. | No |
These states are the public contract. Internal verification details — the checks performed, review reasons, and provider specifics — are not exposed on the API. Build against the states above only.
Deposit method deprecation
Deposit methods identify how origin funds reach us for a corridor. The generic method is being retired in favor of corridor-specific types.
The generic LOCALBANK deposit type is deprecated. Use the corridor-specific types instead — for example SEPA, PIX, and the country-specific bank types — which you can discover per currency via GET /v1/currencies/{currency}/payin-schema. Existing integrations must continue to handle LOCALBANK on historical records.