Force a transaction to a terminal state (sandbox only)
Requests a sandbox terminal transition for the transaction. outcome is completed or failed; the transaction type decides whether its current phase can accept that terminal outcome. For fiat withdrawals, outcome: "failed" can run as soon as POST /v2/payouts accepts the payout, including pending and reserve-in-flight windows; outcome: "completed" belongs to the settlement-ready path. The transaction publishes the matching public event (transaction.completed / transaction.failed for withdrawals and deposits; order.succeeded / order.failed for ONRAMP / OFFRAMP) with the same shape it would in production, and the matching terminal status is recorded atomically. utr (only meaningful on completed) is the synthetic settlement reference; defaults to sandbox-utr-<transactionId> when omitted. reason defaults to a generic sandbox-driven sentinel. On failed, reserved funds are released and any booked transfers are reversed. Supported types today: WITHDRAWAL, ONRAMP, OFFRAMP, DEPOSIT. Calls against INTERNAL_TRANSFER return 422 SANDBOX_TRANSACTION_TYPE_NOT_SIMULATABLE. Replays (caller asks outcome: "completed" against a transaction already settled failed, or vice versa) return the Transaction at its actual terminal state, with status reflecting reality, not the verb the caller used. A 200 response always carries the transaction at a terminal status (completed / failed); the endpoint waits for the terminal state to be recorded before responding. In the rare case it has not been recorded within the wait budget, it returns 503 SERVICE_UNAVAILABLE rather than a still-processing body, so retry the read (GET /v2/transactions/{id}) or the call.
Authorizations
Path Parameters
Body
completed, failed Settlement reference (UTR / on-chain tx hash) attached to the synthetic transaction.completed event. Only meaningful when outcome is completed. Defaults to sandbox-utr-<transactionId> when omitted.
1 - 120Free-text reason persisted as the transaction's failure / completion reason. Defaults to a generic sandbox-driven sentinel when omitted.
1 - 500Response
The transaction at its terminal state
Client-facing view of an outbound withdrawal (debit out of a customer VA/wallet).
^txn_[0-9A-Za-z]{22}$^cus_[0-9A-Za-z]{22}$pending, processing, completed, failed, cancelled One side (source or destination) of a transaction. Discriminated by type.
- Option 1
- Option 2
- Option 3
- Option 4
- Option 5
- Option 6
- Option 7
- Option 8
One side (source or destination) of a transaction. Discriminated by type.
- Option 1
- Option 2
- Option 3
- Option 4
- Option 5
- Option 6
- Option 7
- Option 8
ISO 8601 timestamp
"2026-01-15T09:30:00.000Z"
True when at least one published (non-draft, non-cancelled) RFI targets this transaction. Always present; derived at read time, no stored column.
withdrawal Display name of the customer that owns the transaction: business legal name or individual full name. Same value on the transactions and payouts reads for the same row. Omitted when the customer's identity record hasn't resolved a name yet; per the public omit-don't-null convention, absence is never surfaced as null.
Client-supplied reference, unique per resource within your organization. 1-255 characters from A-Za-z, 0-9, underscore, hyphen, colon, and period — no spaces.
^[A-Za-z0-9_\-:.]{1,255}$Progress signal for a non-terminal transaction, informational only — it does not replace requiresUserSignature, hasRfi, or failureCode for deciding whether your integration needs to act. awaiting_signature: waiting on the required transaction signature (see requiresUserSignature). awaiting_customer_action: further input is needed from your customer — details arrive on the matching event (e.g. transaction.awaiting_sender_information); this is NOT an RFI, hasRfi does not cover it. under_review: compliance, document, or verification review of something already submitted is in progress — usually no action needed; check hasRfi if unsure. settling: funds movement or settlement is in progress, no customer action required — covers long-lived fiat rails like SWIFT that legitimately take days as well as any other non-blocked in-flight state. Omitted once status reaches a terminal value (completed / failed / cancelled). The set of values may grow over time — treat unrecognized values the same as processing.
awaiting_signature, awaiting_customer_action, under_review, settling ISO 8601 timestamp
"2026-01-15T09:30:00.000Z"
user_signature_timeout, user_signature_expired, user_signature_declined, user_signature_rejected_by_provider, crypto_wallet_misconfigured, compliance_hold, compliance_review_rejected, compliance_rejected, returned_by_sender, rail_policy_rejected, insufficient_funds, insufficient_funds_at_settle, rail_unavailable, sender_info_timeout, travel_rule_rejected, provider_rejected, chain_broadcast_failed, roster_changed Human-readable description of failureCode. Defaults to the public error catalog text for the code; sandbox-driven failures may carry the operator-supplied reason instead.
ISO-8601 timestamp when the transaction was cancelled. Present only on status: cancelled.
"2026-01-15T09:30:00.000Z"
Machine-readable cancellation reason. client_cancelled when the client called POST /v2/payouts/:id/cancel; expired is reserved. Omitted on non-cancelled rows. Mirrors orders.cancellationReason.
expired, client_cancelled ^ord_[0-9A-Za-z]{22}$The business purpose declared at payout creation. Drives compliance gating: intercompany requires a whitelisted recipient; other values require supporting documentation.
intercompany, treasury_management, payment_for_goods_or_services, payroll, investments, other, prefunding The most recently published such RFI. Omitted (never null) when hasRfi is false.
^rfi_[0-9A-Za-z]{22}$Position in the per-(wallet, chain) signing queue. Only waiting payouts (position ≥ 1) expose this field; the active/head payout omits it. Absent when the payout is not on the user-signature path or has reached a terminal status.
1 <= x <= 9007199254740991