Get a transaction by ID
Returns a single transaction owned by the caller’s organization. Response shape matches one row of the list endpoint’s data[], discriminated by type.
Authorizations
Path Parameters
"txn_1A2b3C4d5E6f7G8h9I0jKl"
Response
The requested transaction
- Option 1
- Option 2
- Option 3
- Option 4
- Option 5
- Option 6
- Option 7
Client-facing view of an inbound deposit (fiat or crypto credit into 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
- Option 9
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
- Option 9
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.
deposit 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 before the transaction can go on. Read hasRfi to learn where the ask is: true means a request for information holds the answer — rfiId names it, and GET /v2/rfis/{id} carries what to send; false means the matching event carries the detail (e.g. transaction.awaiting_sender_information); with no such event, the recipient details cannot be sent as given, so contact support to correct them, or cancel the payout. 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, insufficient_onchain_balance, source_account_unavailable, capability_suspended Conduit's own wording for failureCode: the public error catalog text for the code, or the generic failure text when there is no code. The same text as failureMessage on the transaction.failed webhook. It never carries text from a bank, a chain or a sandbox simulator reason.
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; conduit_cancelled when Conduit cancelled the payout; expired is reserved. The set of values can grow: treat an unknown value as Conduit ending the transaction. Omitted on non-cancelled rows. Orders carry only client_cancelled and expired.
expired, client_cancelled, conduit_cancelled ^ord_[0-9A-Za-z]{22}$The business purpose declared at payout creation. Drives compliance gating: intercompany requires a whitelisted recipient of the customer or its group; personal_transfer_of_funds requires the customer's own whitelisted account; prefunding requires a customer's issued account; other values require supporting documentation.
intercompany, treasury_management, payment_for_goods_or_services, payroll, investments, other, prefunding, purchase_of_goods, rent, loan_payment, personal_transfer_of_funds, gift, bill_payment, charity, tax_payment, person_to_person_transfer The customer's own words for the payment. Omitted when none was sent, and on the transaction list: read the single transaction to get it.
The most recently published such RFI — usually the one stage refers to, but a later unrelated RFI on the same transaction takes this slot instead. Omitted (never null) when hasRfi is false.
^rfi_[0-9A-Za-z]{22}$The free-text reference of the payment. On a payout, the reference the payer supplied, fiat or crypto. On a transfer between two of the customer's own wallets the same value reads on both halves: the withdrawal that sent it and the deposit that credits it. On a deposit from a bank, reference is the text the sender wrote, as the bank passed it on: on ACH, the addenda (the payment-related information); on a wire, the remittance or originator-to-beneficiary information; on RTP, the remittance data; on SEPA, SEPA Instant and Faster Payments, the payment reference. Some banks do not pass the text on. Conduit removes control characters, keeps at most 512 characters, and drops a placeholder such as NOTPROVIDED and an echo of a Conduit ID. Omitted when there is no text. A transfer from another of your own accounts shows the payout's own reference, not the bank's text.
The UETR of the fiat leg — the ISO 20022 unique end-to-end transaction reference. Present whenever the payment carried one, including on a deposit whose source is still external_unknown because the sender has not resolved. The side that carries wire references repeats it — destination.swiftUetr on a payout, source.swiftUetr on a deposit — but not every side does, which is why it reads here as well. A Fedwire message carries a UETR too, so its presence does not mean the payment travelled on SWIFT. Omitted (never null) when the rail supplied none.
The return code the bank sent when it returned this transfer, for example the Nacha code R01 on an ACH return. Present only with failureCode: returned_by_sender, and only when the bank sent a Nacha return code. returnReason says why the bank returned the transfer. The bank's free-text return reason is never returned.
Why the bank returned or refused this transfer, as a Conduit code. Present with failureCode: returned_by_sender when Conduit recorded the bank's return, with or without returnCode. Present with failureCode: provider_rejected when the bank refused the payout before it settled, no funds moved, and the refusal carried a bank code that Conduit maps or the payee check refused the recipient before sending. Absent on a return recorded before this field existed. account_closed: The account is closed. Get new account details. incorrect_account_number: The account details are incorrect. Check them and send again. beneficiary_name_mismatch: The recipient's name does not match the account. Check the name and send again. payment_not_permitted: The bank or account does not accept this payment. invalid_recipient_details: The recipient's name, address or bank fields are missing, too long or invalid. Correct them and submit again. other: The bank gave no specific reason. Contact support for details. The set of values can grow. Treat a value you do not recognise as other. The bank's free-text reason is never sent.
account_closed, incorrect_account_number, beneficiary_name_mismatch, payment_not_permitted, invalid_recipient_details, other ISO-8601 timestamp when Conduit recorded the bank's return of this transfer. Present with failureCode: returned_by_sender when the return is recorded, with or without returnCode.
"2026-01-15T09:30:00.000Z"
Orders that hold a claim on this transfer, oldest first, with how much of it each draws. Present only on a transfer into a funding address that has not failed.
How much of this transfer has gone back, or is on its way back, to the address it came from. A return is counted from the moment it is dispatched, because the funds leave the funding address then — read the deposit_return transaction to see whether it has settled. Present under the same conditions as funded.
How much of this transfer no order has claimed and no return has taken, so it is still available at the funding address to fund the next order. source.assetAmount always equals the sum of funded[].amount plus returned plus available. These three fields appear only on a transfer into a funding address, which is never charged a deposit fee, so on such a transfer source.assetAmount and destination.assetAmount are the same figure and the sum reconciles against either.