Skip to main content
Once a customer is onboarded with a wallet or a Virtual Account, most transactions just work — you call the deposit or payout endpoint and Conduit drives it to settlement. A few need extra information or a document to clear compliance first, and what’s required depends on the transaction. This page is the map: where each flow lives, and what it will ask of you.
Test this flow in sandbox. Drive it end-to-end with simulated money and deterministic controls — start with the sandbox quickstart, then the sandbox overview for this flow, and the cheat sheet for every magic value and simulate endpoint.

​
Pick your flow

The rest of this page covers the requirement gates those flows share. Deposits are submit-and-listen; the gates below are the compliance and documentation requirements a transaction clears before it settles. (Non-custodial crypto payouts have one more ask — your signers co-sign before settlement, via transaction.awaiting_signature; see Non-Custodial Payout. Passkey-mode signers approve on the verify page; a wallet in a programmatic signing mode approves via a signingRequestId instead — see Machine-signer stamping.)

​
Crypto deposits — sender information (Travel Rule)

When crypto arrives from a sender address Conduit doesn’t have registered, the deposit parks instead of settling and fires transaction.awaiting_sender_information (carrying the sourceAddress, the assetAmount, and an expiresAt deadline with daysRemaining). To release it, submit the sender’s (originator’s) details so Conduit can satisfy the Travel Rule:
  • register: false (default) — the details apply to this deposit only.
  • register: true — also saves the address so future deposits from it clear on their own.
Submit before the deadline, or the deposit fails with SENDER_INFO_TIMEOUT. The full deposit walk-through is in Receive Crypto; the originator shape (individual vs business) and the pre-registration path for a wallet the customer owns are in Registered Addresses.

​
Payouts — requirements depend on purpose

Every payout carries a purpose. What the payout needs to clear depends on its value:

​
Intercompany payouts — whitelist the recipient

For purpose: intercompany (first-party / same-group transfers), the recipient must already be registered for the customer — that registration is the compliance evidence, so no per-transaction document is needed. Register it once:
  • Fiat (bank) recipient — POST /v2/customers/{customerId}/whitelist-recipients, then wait for whitelist_recipient.registered (asynchronous review). See Whitelist Recipients.
  • Crypto (address) recipient — POST /v2/customers/{customerId}/wallets/registered-addresses (synchronous). See Registered Addresses.
Submit the payout once the recipient is registered. If it isn’t, the payout is rejected at submission with 422 RECIPIENT_NOT_WHITELISTED.

​
Other purposes — attach a supporting document

For any other purpose, the payout needs a supporting document, and the system tells you so by rejecting and asking you to retry with the document attached:
  1. Submit the payout. With no document, it’s rejected at submission with 422 DOCUMENTATION_REQUIRED — no payout is created.
  2. Upload the document, tagged for transaction support:
  1. Resubmit the payout with the returned doc_* id in documents[] and a new idempotency-key — attaching the document changes the request body, and the original key is already bound to the no-document attempt, so reusing it returns 409 IDEMPOTENCY_KEY_CONFLICT:
Keep that new key for any further retries of the corrected payout — don’t mint another one each time. Reusing the corrected request’s key means a lost response replays the one payout that was accepted instead of creating a second one.
A document accepted at submission can still be reviewed afterward; if it’s found inadequate the payout fails with failureCode: compliance_rejected. The full payout request shape lives in Money Movement (fiat) and Non-Custodial Payout (crypto).

​
Where to go next

Receive Crypto

Inbound crypto end to end, including the sender-information gate.

Money Movement

Fiat funding and payouts end to end.

Non-Custodial Payout

Co-signed crypto payouts.

Whitelist Recipients

Registering intercompany recipients.