Withdrawals in sandbox

Compliance, Travel Rule and fiat settlement on this page are mocked: no third-party vendor calls, and every outcome is deterministic and driven by your request data (destination-address suffixes or bank-account suffixes) or by sandbox-only simulate/* endpoints. Crypto broadcast and signing are real. See Sandbox overview for the full posture. This page walks the full lifecycle of both withdrawal types end-to-end:

Crypto withdrawal: real testnet broadcast, signed by the customer’s roster; finality takes minutes.
Fiat withdrawal: bank-recipient payout. It settles on its own unless the account number asks for a specific outcome — see the fiat account-number suffix catalog.

Crypto withdrawal on real testnet

A non-custodial crypto payout on POST /v2/payouts behaves like production:

It broadcasts for real. The payout broadcasts from the wallet on its own testnet (Sepolia, Base Sepolia, Amoy, Solana Devnet), and transaction.completed carries a real txHash you can open on that network’s block explorer.
It needs a real signature. The payout parks at transaction.awaiting_signature. A passkey_required wallet approves through the webhook’s verificationUrl; a programmatic wallet carries a signingRequestId your backend stamps at POST /v2/signing-requests/:id/approve (Machine-signer stamping) — there is no simulate shortcut.
Fund the source wallet from a faucet. Send real test tokens to the wallet address, then withdraw. See Use a real testnet for faucets, finality thresholds, and explorers.
It takes minutes to reach finality. Wait for transaction.completed.

The request body, queue behaviour, and document-review gate are identical to the walkthrough below; only broadcast, signing, and finality are real.

Withdrawal state machine

A payout parks for review — a missing or not-yet-approved document, a compliance hold, or both — before any signer is asked to approve. It reads stage: "under_review", or stage: "awaiting_customer_action" with hasRfi: true when Conduit is asking you for something. transaction.under_review fires once per review period. In sandbox, release it with POST /v2/sandbox/payouts/:id/simulate-review-approve, or end it with simulate-review-reject — which fails the payout with failureCode: compliance_rejected and returns the reserved funds. A payout the documentation policy requires no document for (intercompany and personal_transfer_of_funds payouts, which use a whitelist recipient, and by default prefunding payouts) skips this gate. Once compliance and document review clear, transaction.processing fires and the payout enters processing. For a crypto payout to a VASP-attributed destination, Conduit resolves Travel Rule here — after processing starts, before any signature is requested. See Travel Rule scenarios. A non-custodial crypto payout then parks for the customer’s signature: transaction.awaiting_signature carries the signing details, and on a multi-signer wallet transaction.signature_collected tracks quorum progress until transaction.quorum_met fires. The payout broadcasts on the testnet and reaches completed at real chain finality (minutes). A fiat payout submits to the mocked rail during processing. An account number matching no suffix in the fiat account-number suffix catalog settles on its own; a 94009004 suffix leaves it reserved until POST /v2/sandbox/payouts/:id/simulate/settled supplies the bank’s final answer. POST /v2/sandbox/transactions/:id/simulate/terminal { outcome: "failed" } can also force an accepted fiat payout to failed once the document-review gate is clear; outcome: "completed" requires a settlement-ready payout. This endpoint also supports onramp, offramp, and deposit transactions.

Prerequisites

Your organization’s sandbox API key, and an active customer (the onboarding flow leaves the customer in this state). Set SANDBOX_API_KEY in your shell.
The customer must have an active crypto wallet for the asset and chain you want to test. New customers provision non-custodial wallets via POST /v2/customers/:id/wallets/claim-non-custodial; without that claim, POST /v2/customers/:id/wallets rejects with 422 WALLET_NO_PROVIDER_ACCOUNT (no custody yet to create the wallet against).
For fiat withdrawals: the customer must have an active virtual account with a sufficient USD balance.
Base URL: https://api.sandbox.conduit.financial.

All curl examples below use YOUR_API_KEY, {{customerId}}, {{walletId}}, and {{payoutId}} placeholders. Substitute the values from your sandbox setup.

Lifecycle

A sandbox payout walks the same lifecycle as production: validate → reserve → compliance and document review (if your policy requires one) → processing → Travel Rule resolve (crypto only) → collect the customer’s signature → broadcast → await finality → settle (fiat). Compliance and document review run before the customer is asked to sign, so screening happens before any signature is requested — the customer never signs a payment that then fails screening. A compliance rejection does not stop the payout automatically: it is held for review and then either released to proceed or confirmed as terminal (rejected or frozen); on a confirmed rejection the payout never broadcasts. The lifecycle is identical to production; only the decisions differ:

Step	Production	Sandbox
compliance screen	Real upstream call	Mock; outcome from `destination.address` suffix
Travel Rule create	Real upstream call (VASP destinations)	Mock; a transfer is created only when the destination suffix matches a VASP scenario
Cosign (non-custodial)	Customer passkey on verify page	Real signature: a passkey on the verify page, or a machine stamp at `POST /v2/signing-requests/:id/approve`
Document review (payouts policy requires a document for)	Conduit classifies the supporting documents and records the result as advice on the review; a compliance analyst gives the verdict	`payouts/:id/simulate-review-approve` to resume the payout, or `payouts/:id/simulate-review-reject` to terminate it as `failed` with `failureCode: compliance_rejected` (reserved funds returned).
Compliance hold	A compliance analyst releases or rejects the payout	The same two levers release or reject every review holding the payout — a payout never reports which ones. `simulate-review-approve` releases them all and returns once the payout has left review; `simulate-review-reject` terminates it as `failed`. A rejected compliance hold resolves asynchronously: wait for `transaction.failed`. `simulate-review-approve` answers `409 CONFLICT` when a verdict on the review already stands — reject it instead — and also once a Conduit analyst has sent a request for information on the payout, because Conduit then completes the review itself; `simulate-review-reject` still ends the payout in either case.
Chain broadcast	Mainnet	Real public testnet; real `txHash`
Counterparty webhook	Real upstream delivery	Counterparty-webhook autopilot fires 10s after the Travel Rule transfer is created when the destination suffix encodes a counterparty outcome (`BAD6A1A4`, `DEC11A1D`, `ACCEEDED`). Conduit creates that transfer after compliance and document review clear, just before the payout asks for a signature, so the 10s clock starts there, not at payout creation. The VASP-attributed suffix `5A50AB1E` opens the Travel Rule gate but does not auto-resolve — call `payouts/:id/simulate/counterparty-webhook` manually.
Chain finality	Real chain confirmation	Real testnet confirmation (minutes)
Fiat settlement	Real rail settlement	`POST /v2/sandbox/payouts/:id/simulate/settled`

Full happy path: non-custodial crypto withdrawal

A non-custodial wallet’s signingThreshold decides the shape of this walkthrough: 1 gives a single-signer wallet, where one signer’s stamp clears each payout; a higher M-of-N threshold gives a multi-signer wallet, where each signer stamps independently and the payout auto-broadcasts once the threshold is met. Every step below is the same either way, except where noted. For the mental model see Multi-signer wallets; for threshold rules see Signing thresholds; for the copy-paste walkthrough see Multi-signer wallets recipe.

Step 1 — Provision the roster

Call POST /v2/customers/{customerId}/wallets/claim-non-custodial with a roster (admins + signers, each with a unique email) and a signingThreshold. The endpoint returns 202 with a claimId and dispatches one wallet_signer.invited webhook per roster member.

Step 2 — Enroll each signer and read the wallet

Each signer opens the verificationUrl from their wallet_signer.invited payload and enrolls a passkey on their device, in sandbox as in production (a machine roster needs no enrollment). Once the final signer enrolls, crypto_wallet.completed fires and the wallet flips active. The claim already made a wallet on each chain you named; read them with GET /v2/customers/:customerId/wallets and capture the id of the one you want to test as {{walletId}}. To add a wallet on a chain outside the claim (for example solana), call POST /v2/customers/:customerId/wallets with { "chain": "solana" }.

Step 3 — Fund the wallet

Send real testnet funds from a faucet (fund a wallet from a faucet) to the wallet address. A faucet sends from an address you have not registered, so the deposit parks awaiting sender information — send POST /v2/transactions/:id/sender-information with register: true the first time; later deposits from that same address pass straight through. Wait for transaction.completed on the deposit before creating the payout.

A non-custodial wallet+chain signs one payout at a time. Additional payouts queue at a positive queuePosition (1 is next in line). Follow the place with the transaction.queue_position_changed webhook, which fires on entry to the queue and on each move forward — no polling needed; the same value is also on GET /v2/payouts/:id. The queue is bounded — once full, POST /v2/payouts returns 422 PAYOUT_QUEUE_FULL. See PAYOUT_QUEUE_FULL reference.

Step 4 — Create the payout

curl -X POST https://api.sandbox.conduit.financial/v2/payouts \
  -H "x-api-key: YOUR_API_KEY" \
  -H "idempotency-key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "customerId": "{{customerId}}",
    "assetAmount": {
      "code": "USDC",
      "chain": "ethereum",
      "amount": "10.000000"
    },
    "destination": {
      "type": "crypto",
      "recipient": {
        "chain": "ethereum",
        "address": "0xaa11aa11aa11aa11aa11aa11aa11aa11a55ee99c",
        "attestation": { "custody": "self" }
      }
    },
    "purpose": "treasury_management",
    "documents": ["{{docId}}"]
  }'

const res = await fetch(`${process.env.SANDBOX_HOST}/v2/payouts`, {
  method: "POST",
  headers: {
    "x-api-key": process.env.SANDBOX_API_KEY!,
    "idempotency-key": crypto.randomUUID(),
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    customerId,
    assetAmount: { code: "USDC", chain: "ethereum", amount: "10.000000" },
    destination: {
      type: "crypto",
      recipient: {
        chain: "ethereum",
        address: "0xaa11aa11aa11aa11aa11aa11aa11aa11a55ee99c",
        attestation: { custody: "self" },
      },
    },
    purpose: "treasury_management",
    documents: [docId],
  }),
});
const payout = await res.json();

import httpx, os, uuid

r = httpx.post(
    f"{os.environ['SANDBOX_HOST']}/v2/payouts",
    headers={
        "x-api-key": os.environ["SANDBOX_API_KEY"],
        "idempotency-key": str(uuid.uuid4()),
        "Content-Type": "application/json",
    },
    json={
        "customerId": customer_id,
        "assetAmount": {"code": "USDC", "chain": "ethereum", "amount": "10.000000"},
        "destination": {
            "type": "crypto",
            "recipient": {
                "chain": "ethereum",
                "address": "0xaa11aa11aa11aa11aa11aa11aa11aa11a55ee99c",
                "attestation": {"custody": "self"},
            },
        },
        "purpose": "treasury_management",
        "documents": [doc_id],
    },
)
payout = r.json()

202 Accepted with { "id": "txn_...", "status": "pending", "requiresUserSignature": true, ... }. Capture the id as {{payoutId}}. queuePosition is not in the create response — see the queue note above if the wallet+chain is already signing another payout. The documents array must contain the id from a prior POST /v2/documents upload — a payout without one is either refused with 422 DOCUMENTATION_REQUIRED, or accepted and parked for review at stage: "awaiting_customer_action" with hasRfi: true (an organization with contacts configured for requests for information; see Send a payout). Because the documentation policy requires a document for this purpose, the payout first parks for document review (Step 5). Only once that clears does transaction.processing fire; Conduit then resolves Travel Rule for a VASP-attributed destination before the payout parks for the customer’s signature, at which point transaction.awaiting_signature fires with verificationUrl and expiresAt — carrying a signingRequestId instead for a programmatic wallet (Machine-signer stamping).

Step 5 — Approve the document review

Clear it first:

curl -X POST https://api.sandbox.conduit.financial/v2/sandbox/payouts/{{payoutId}}/simulate-review-approve \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json"

Usually 200 OK; if the review has not cleared by the time the call returns, you get 503 SERVICE_UNAVAILABLE — the release still stands, so retry the call or read GET /v2/payouts/:id. Call simulate-review-reject instead to terminate the payout as failed with failureCode: compliance_rejected (reserved funds returned).

Step 6 — Approve the payout

A single-signer wallet (signingThreshold: 1) needs one approval: a signer opens the verificationUrl from transaction.awaiting_signature and approves with their passkey, or a programmatic wallet stamps the signingRequestId at POST /v2/signing-requests/:id/approve instead (Machine-signer stamping). The payout then broadcasts on the testnet and reaches completed at real chain finality (minutes). A decline fails the payout with failureCode: "user_signature_declined". A multi-signer wallet needs quorum instead: each signer opens the verificationUrl on the device where they enrolled and approves independently. transaction.signature_collected carries the running collected and required counts; once collected reaches required, transaction.quorum_met fires and the payout broadcasts the same way. Rejection. A single decline terminalizes a multi-signer quorum and fails the payout with failureCode: "user_signature_declined". The remaining signers cannot un-reject. Re-stamping. A second approval by the same signer does not double-count, and transaction.signature_collected reports the same collected count. Signer removed mid-payout. If a signer is removed from the roster while a payout is collecting stamps (via DELETE /v2/customers/:id/wallet-signers/:signerId), their already-cast stamps are scrubbed from every in-flight payout for the customer. Affected payouts re-fire transaction.signature_collected with the new count; a payout that can no longer reach quorum on the new roster terminates with failureCode: "roster_changed". See Signer removed mid-payout for the walkthrough.

Fiat withdrawal

A fiat withdrawal moves funds from a customer’s virtual account to a bank account. The payout is submitted to the configured payment rail; in sandbox the rail call is mocked, and the recipient’s account number selects the outcome (see the catalog below).

Step 1 — Create the fiat payout

curl -X POST https://api.sandbox.conduit.financial/v2/payouts \
  -H "x-api-key: YOUR_API_KEY" \
  -H "idempotency-key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "customerId": "{{customerId}}",
    "virtualAccountId": "{{virtualAccountId}}",
    "assetAmount": { "code": "USD", "amount": "25.00" },
    "destination": {
      "type": "fiat",
      "rail": "fedwire",
      "recipient": {
        "type": "business",
        "legalName": "Acme Corp",
        "accountNumber": "1234594000000",
        "routingNumber": "021000021",
        "accountType": "checking",
        "bankAddress": {
          "addressLine1": "1 Bank Plaza",
          "city": "New York",
          "state": "NY",
          "postalCode": "10005",
          "country": "USA"
        },
        "phone": "+12125550100",
        "postalAddress": {
          "addressLine1": "10 Vendor St",
          "city": "New York",
          "state": "NY",
          "postalCode": "10005",
          "country": "USA"
        }
      }
    },
    "purpose": "treasury_management",
    "documents": ["{{docId}}"]
  }'

const res = await fetch(`${process.env.SANDBOX_HOST}/v2/payouts`, {
  method: "POST",
  headers: {
    "x-api-key": process.env.SANDBOX_API_KEY!,
    "idempotency-key": crypto.randomUUID(),
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    customerId,
    virtualAccountId,
    assetAmount: { code: "USD", amount: "25.00" },
    destination: {
      type: "fiat",
      rail: "fedwire",
      recipient: {
        type: "business",
        legalName: "Acme Corp",
        accountNumber: "1234594000000",
        routingNumber: "021000021",
        accountType: "checking",
        bankAddress: {
          addressLine1: "1 Bank Plaza",
          city: "New York",
          state: "NY",
          postalCode: "10005",
          country: "USA",
        },
        phone: "+12125550100",
        postalAddress: {
          addressLine1: "10 Vendor St",
          city: "New York",
          state: "NY",
          postalCode: "10005",
          country: "USA",
        },
      },
    },
    purpose: "treasury_management",
    documents: [docId],
  }),
});
const payout = await res.json();

import httpx, os, uuid

r = httpx.post(
    f"{os.environ['SANDBOX_HOST']}/v2/payouts",
    headers={
        "x-api-key": os.environ["SANDBOX_API_KEY"],
        "idempotency-key": str(uuid.uuid4()),
        "Content-Type": "application/json",
    },
    json={
        "customerId": customer_id,
        "virtualAccountId": virtual_account_id,
        "assetAmount": {"code": "USD", "amount": "25.00"},
        "destination": {
            "type": "fiat",
            "rail": "fedwire",
            "recipient": {
                "type": "business",
                "legalName": "Acme Corp",
                "accountNumber": "1234594000000",
                "routingNumber": "021000021",
                "accountType": "checking",
                "bankAddress": {
                    "addressLine1": "1 Bank Plaza",
                    "city": "New York",
                    "state": "NY",
                    "postalCode": "10005",
                    "country": "USA",
                },
                "phone": "+12125550100",
                "postalAddress": {
                    "addressLine1": "10 Vendor St",
                    "city": "New York",
                    "state": "NY",
                    "postalCode": "10005",
                    "country": "USA",
                },
            },
        },
        "purpose": "treasury_management",
        "documents": [doc_id],
    },
)
payout = r.json()

202 Accepted with { "id": "txn_...", "status": "pending", ... }. Capture the id as {{payoutId}}. Compliance screening runs automatically; in sandbox it resolves based on the account-number suffix (see catalog below). The accountNumber 1234594000000 ends in the last 8 digits 94000000 which is the happy-path suffix. Because the documentation policy requires a document for this purpose, the payout then parks for document review (status: "pending", stage: "under_review") before settlement — clear the gate in the next step.

purpose and documents are required. Every payout except purpose: intercompany, purpose: personal_transfer_of_funds and, by default, purpose: prefunding needs at least one documents entry to take this happy path (documentation policy can still require documents on a prefunding payout above a configured amount). When the payout requirements return documentation.due: post_acceptance, Conduit accepts the payout without one and asks for the document at the review gate. Upload a supporting document first (POST /v2/documents) and pass its id in the documents array. intercompany and personal_transfer_of_funds payouts use a registered whitelist recipient instead of a document — see Whitelist Recipients. A prefunding payout must also be sent from a house account — a Conduit-issued account you fund your own customers’ payouts from (see Send a payout): your sandbox organization is seeded with one, or mark a BUSINESS customer you onboarded yourself with PATCH /v2/sandbox/customers/{customerId}/house-account.

Step 2 — Approve the document review (sandbox only)

A fiat payout the documentation policy requires a document for parks for document review before it is submitted to the rail, exactly like the crypto flow. Approve it to let settlement proceed:

curl -X POST https://api.sandbox.conduit.financial/v2/sandbox/payouts/{{payoutId}}/simulate-review-approve \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json"

Usually 200 OK returning the payout at its current state; if the review has not cleared by the time the call returns, you get 503 SERVICE_UNAVAILABLE — the release still stands, so retry the call or read GET /v2/payouts/:id. Call simulate-review-reject instead to terminate the payout as failed with failureCode: compliance_rejected; transaction.rejected fires and the reserved funds return to the virtual account.

Step 3 — Drive settlement (only when the bank’s answer is still pending)

A recipient account number matching no suffix below — including the happy-path example from Step 1 — settles on its own at submission: wait for transaction.completed, no extra call needed. simulate/settled exists for the one scenario where the bank’s answer is still pending: an account number ending in 94009004 leaves the payout reserved until you supply the bank’s final answer.

curl -X POST https://api.sandbox.conduit.financial/v2/sandbox/payouts/{{payoutId}}/simulate/settled \
  -H "x-api-key: YOUR_API_KEY" \
  -H "idempotency-key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "outcome": "completed",
    "utr": "IMAD-20260115-001"
  }'

const res = await fetch(
  `${process.env.SANDBOX_HOST}/v2/sandbox/payouts/${payoutId}/simulate/settled`,
  {
    method: "POST",
    headers: {
      "x-api-key": process.env.SANDBOX_API_KEY!,
      "idempotency-key": crypto.randomUUID(),
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ outcome: "completed", utr: "IMAD-20260115-001" }),
  },
);
// returns the payout at its current state

import httpx, os, uuid

r = httpx.post(
    f"{os.environ['SANDBOX_HOST']}/v2/sandbox/payouts/{payout_id}/simulate/settled",
    headers={
        "x-api-key": os.environ["SANDBOX_API_KEY"],
        "idempotency-key": str(uuid.uuid4()),
        "Content-Type": "application/json",
    },
    json={"outcome": "completed", "utr": "IMAD-20260115-001"},
)
# returns the payout at its current state

200 OK returning the payout at its current state. The outcome field is "completed" or "failed". utr is optional on a "completed" outcome — when supplied, it must be a non-empty bank reference (IMAD, UETR, ACH trace number, or instant-payment reference). The payout transitions to status: "completed", completedAt is populated, and transaction.completed fires carrying that reference on the destination’s typed wire-reference field for the rail (e.g. external_bank.fedwireImad, external_bank.swiftUetr). When the sandbox bank already settled the wire on its own, the payout keeps the bank’s reference, and this call’s utr and reason are ignored. To drive a failure instead, use outcome: "failed" with an optional reason string — reason becomes free-form text on the failure, never a failureCode:

curl -X POST https://api.sandbox.conduit.financial/v2/sandbox/payouts/{{payoutId}}/simulate/settled \
  -H "x-api-key: YOUR_API_KEY" \
  -H "idempotency-key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{ "outcome": "failed", "reason": "sandbox-forced failure" }'

transaction.failed fires with rail_unavailable — every simulate/settled failure carries this code; reason only becomes the human-readable message. To get a specific failure code instead, drive it through the account-number suffix catalog below — for example, an account ending in 94009002 fails at settlement with insufficient_funds_at_settle, with no call to this endpoint needed.

Fiat account-number suffix catalog

The sandbox reads the last 8 digits of recipient.accountNumber (all non-digit characters stripped before matching) to select a deterministic outcome. Choose an accountNumber whose tail matches the desired scenario when you build the payout’s destination.recipient.

Last 8 digits	Scenario	failureCode	Webhook
`94000000`	Happy path — settlement completes	—	`transaction.completed`
`94009001`	Rail policy rejects (amount limit, frequency cap, or recipient restriction)	`rail_policy_rejected`	`transaction.failed`
`94009002`	Insufficient funds at settlement (funds were available at reservation)	`insufficient_funds_at_settle`	`transaction.failed`
`94009003`	No viable rail available for the corridor	`rail_unavailable`	`transaction.failed`
`94009004`	Bank timeout; settlement remains unknown	None while unresolved	None until settled

Accounts not matching any documented suffix take the happy path (94000000 behavior).

Routing-number directory

On a US rail (fedwire, rtp, fednow, ach, ach_same_day), destination.recipient.bankAddress is optional. Omit it and Conduit derives the recipient bank’s name and address from routingNumber. In sandbox every routing number resolves to Simulated National Bank, except 999999992, which the directory does not hold. An unheld routing number returns 400 VALIDATION_ERROR with pointer /destination/recipient/bankAddress, exactly as production does for a routing number the real directory does not hold. When the directory cannot answer at all, the payout returns 503 RECIPIENT_BANK_LOOKUP_UNAVAILABLE, which is retryable and says nothing about the routing number you sent. A request that supplies both bankAddress and bankName never consults the directory. Supplying bankAddress alone still consults it to fill the missing bankName, and the payout still goes through when the directory cannot answer, because bankName is optional. A bankName you send is never overwritten.

Suffixes 94009001–94009003 produce a bank rejection at settlement with no simulate/settled call needed (see the catalog above). 94009004 is the exception: it leaves the payout reserved, because a timeout does not prove the bank rejected the transfer, and only simulate/settled can supply the bank’s final answer. The payout reaches a terminal state only after that answer arrives; calling a simulation endpoint after settlement preserves the recorded outcome.

Failure paths

Fiat payouts can also be failed with POST /v2/sandbox/transactions/:id/simulate/terminal with { "outcome": "failed" } after payout acceptance, once the document-review gate is clear. While that gate is open the call returns 422 SANDBOX_TRANSACTION_NOT_FORCE_TERMINAL_READY. A payout in an in-progress phase with no transfer reference the simulation can drive yet returns the same 422 for either outcome; retry the call, or read the payout’s status and stage with GET /v2/payouts/:id if it keeps refusing. The same endpoint with { "outcome": "completed", "utr": "..." } requires a settlement-ready payout; calling it before the API has selected a settlement route returns 422 SANDBOX_TRANSACTION_NOT_FORCE_TERMINAL_READY. Other primary sandbox failure paths:

Compliance reject

Send to a destination address whose last 8 characters match one of the compliance-reject suffixes (5A4D4EE5, 5A4D4E5A). The compliance mock resolves the address to a rejected decision, and the payout is held for compliance review — it keeps status: "pending", not an automatic failure. Resolve it with POST /v2/sandbox/transactions/:id/simulate/compliance-decision: { "outcome": "reject" } terminates it as failed with compliance_review_rejected (no on-chain broadcast). Once compliance has rejected the payout, { "outcome": "approve" } is not available — a rejected case can only be terminalized via reject. Full catalog: consolidated withdrawal address-suffix catalog.

Document-review reject

A payout the documentation policy requires a document for parks for document review. Call POST /v2/sandbox/payouts/:id/simulate-review-reject (no body) to reject it:

curl -X POST https://api.sandbox.conduit.financial/v2/sandbox/payouts/{{payoutId}}/simulate-review-reject \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json"

200 OK returning the payout at its current state. The payout terminates as status: "failed" with failureCode: compliance_rejected, transaction.rejected fires (not transaction.failed), and the reserved funds return to the source balance. Calling it again after the payout is already terminal is safe: it returns 200 OK with the payout at its current state, unchanged. 404 PAYOUT_NOT_FOUND applies only when the payout was never a withdrawal belonging to your organization, or was never parked for a review this call can resolve. To re-attempt, upload an acceptable document and submit a new payout with a fresh idempotency-key.

Travel Rule paths

Use a VASP-attributed destination (suffix 5A50AB1E) to route the payout through the Travel Rule flow. Drive the counterparty leg either with auto-pilot suffixes (AC6BC0DE, ACCEEDED, BAD6A1A4, DEC11A1D) or pre-empt the 10-second timer by calling POST /v2/sandbox/payouts/:id/simulate/counterparty-webhook with { "outcome": "acknowledged" | "approved" | "rejected" | "declined" }. Before broadcast, rejected and declined terminate the payout as status: "failed" with failureCode: travel_rule_rejected. Once the payout has broadcast, the same call is audit-only: the on-chain transfer cannot be reversed, so the payout completes. Full catalog (including pre-broadcast Travel Rule failures): Travel Rule scenarios.

Cancelling a payout

Sandbox uses the production cancel contract — see POST /v2/payouts/:id/cancel for state-based rules and error codes. Two sandbox-specific deltas:

The reliably scriptable cancel window is the non-custodial wallet’s signing gate. A fiat payout hands off to the rail inline once compliance clears (same as production), so its cancel window is a narrow race you usually can’t observe from a test.
There is no “force-cancel” simulate endpoint. To drive failed on fiat in sandbox, use the failure-suffix protocol (see Failure paths) or POST /v2/sandbox/transactions/:id/simulate/terminal { outcome: "failed" }.

Webhook events

Every webhook your production endpoint would receive also fires in sandbox, with synthesized data. Configure the sandbox endpoint via the dashboard or POST /v2/webhooks/endpoints exactly like production. See the Webhooks reference for the full payout event list, payload schemas, and the failureMessage symmetry contract covering the exact rules across the transaction record, GET, and the webhook payload.

Address-suffix matching rules

EVM (Ethereum / Base / Polygon): last 8 hex characters of the address, case-insensitive. 0x...DEADBEEF matches suffix DEADBEEF.
Solana: last 8 Base58 characters, case-sensitive.
Fiat (bank account): last 8 digits of recipient.accountNumber, all non-digit characters stripped before matching.

The address must be valid for its chain; sandbox does not bypass on-chain address validation. An address with no matching suffix takes the real broadcast path, the same as a happy-path address: compliance APPROVED, self-hosted Travel Rule resolution, straight to broadcast.

Consolidated withdrawal address-suffix catalog

Every suffix that is meaningful on a withdrawal destination address. Suffixes match the last 8 characters of the destination address (lowercased hex for EVM; Base58 verbatim for Solana). For the wallet-screening and counterparty-outcome suffixes, see the Wallet screening catalog and the Counterparty-outcome catalog. The full programmatic list is the Scenario suffix table.

Suffix	Class	Outcome	Auto-pilot?
`5A4D4EAA`	compliance approved	Happy path; proceeds to broadcast.	n/a
`5A4D4EE5`	compliance rejected	Held for compliance review (`status: pending`); `simulate/compliance-decision` `reject` → `transaction.failed` with `compliance_review_rejected`.	n/a
`5A4D4E5A`	compliance sanctions match	Held for compliance review (`status: pending`); `simulate/compliance-decision` `reject` → `transaction.failed` with `compliance_review_rejected`.	n/a
`5A4D4E51`	compliance elevated risk	Routes approved at current threshold; no observable difference.	n/a
`5A4D4E9E`	compliance review pending	Withdrawal pauses for compliance review; `status: pending`. Resolve via `POST /v2/sandbox/transactions/:id/simulate/compliance-decision` (`approve` → proceeds; `reject` → rejected).	n/a
`5A50AB1E`	VASP wallet	Opens a Travel Rule transfer; the counterparty leg must be driven manually.	No
`5E1F0577`	Self-hosted wallet	No Travel Rule transfer; proceeds to broadcast.	n/a
`12517C00`	Elevated risk (wallet screening)	Self-hosted resolution; the payout proceeds.	n/a
`5A4070ED`	Sanctions match (wallet screening)	Held for compliance review (`status: pending`); `simulate/compliance-decision` `reject` → `transaction.failed` with `compliance_review_rejected`.	n/a
`AC6BC0DE`	Counterparty ACK	Informational ACK; the payout proceeds.	Yes, 10 s after create.
`ACCEEDED`	Counterparty accepted	Counterparty approves; the payout proceeds.	Yes, 10 s.
`BAD6A1A4`	Counterparty rejected	Counterparty rejects (pre-broadcast).	Yes, 10 s.
`DEC11A1D`	Counterparty declined	Counterparty declines (same as rejected).	Yes, 10 s.
`BAD7E517`	Travel Rule validation rejection	Unconditional pre-broadcast Travel Rule reject.	No (deterministic).
`D15CCAD0`	Travel Rule discrepancy	Customer attested the destination is their own wallet but wallet screening identifies a VASP; payout fails with `travel_rule_rejected`.	No
`5A4ED0DD`	Travel Rule non-sendable after create	The Travel Rule transfer resolves to a non-sendable state right after creation; pre-broadcast fail with `travel_rule_rejected`.	No
`DA171465`	Travel Rule waiting for information	The transfer starts waiting for information; broadcast proceeds, and the transfer resolves on its own 10 s after creation.	Yes, 10 s.

Get started

Transaction guides

References

Scenario libraries

Withdrawals in sandbox

Crypto withdrawal on real testnet

Withdrawal state machine

Prerequisites

Lifecycle

Full happy path: non-custodial crypto withdrawal

Step 1 — Provision the roster

Step 2 — Enroll each signer and read the wallet

Step 3 — Fund the wallet

Step 4 — Create the payout

Step 5 — Approve the document review

Step 6 — Approve the payout

Fiat withdrawal

Step 1 — Create the fiat payout

Step 2 — Approve the document review (sandbox only)

Step 3 — Drive settlement (only when the bank’s answer is still pending)

Fiat account-number suffix catalog

Routing-number directory

Failure paths

Compliance reject

Document-review reject

Travel Rule paths

Cancelling a payout

Webhook events

Address-suffix matching rules

Consolidated withdrawal address-suffix catalog

See also

​Crypto withdrawal on real testnet

​Withdrawal state machine

​Prerequisites

​Lifecycle

​Full happy path: non-custodial crypto withdrawal

​Step 1 — Provision the roster

​Step 2 — Enroll each signer and read the wallet

​Step 3 — Fund the wallet

​Step 4 — Create the payout

​Step 5 — Approve the document review

​Step 6 — Approve the payout

​Fiat withdrawal

​Step 1 — Create the fiat payout

​Step 2 — Approve the document review (sandbox only)

​Step 3 — Drive settlement (only when the bank’s answer is still pending)

​Fiat account-number suffix catalog

​Routing-number directory

​Failure paths

​Compliance reject

​Document-review reject

​Travel Rule paths

​Cancelling a payout

​Webhook events

​Address-suffix matching rules

​Consolidated withdrawal address-suffix catalog

​See also

Crypto withdrawal on real testnet

Withdrawal state machine

Prerequisites

Lifecycle

Full happy path: non-custodial crypto withdrawal

Step 1 — Provision the roster

Step 2 — Enroll each signer and read the wallet

Step 3 — Fund the wallet

Step 4 — Create the payout

Step 5 — Approve the document review

Step 6 — Approve the payout

Fiat withdrawal

Step 1 — Create the fiat payout

Step 2 — Approve the document review (sandbox only)

Step 3 — Drive settlement (only when the bank’s answer is still pending)

Fiat account-number suffix catalog

Routing-number directory

Failure paths

Compliance reject

Document-review reject

Travel Rule paths

Cancelling a payout

Webhook events

Address-suffix matching rules

Consolidated withdrawal address-suffix catalog

See also