Use cases

What you can build

Every payment is one origin leg and one destination leg. Pick where the money comes from and where it goes — this page lists every rail available on each side, and the exact fields each one needs. Whether a specific origin → destination pair is enabled for your workspace is a separate question: ask GET /v1/pairs.

14 currencies you can hold 31 currencies you can collect 32 payout rails

Start here: the four combinations below are the whole API surface. Once you know which one you need, jump to its section — then use the reference tables at the bottom for the exact fields of your currency and rail.

How this fits together

Every payment is one origin leg and one destination leg. Each leg is either a rail (money moving in the real world) or a balance (funds already sitting in your workspace). Those two choices decide everything — which endpoints you call, and which fields you send.

Origin	Destination	What it is	Endpoints
rail	balance	Collect — a pay-in that credits your balance	`POST /v1/deposits`	Collect →
rail	rail	Cross-border payment — collect in one currency, pay out in another. Fiat → crypto is an on-ramp; crypto → fiat an off-ramp	`POST /v1/quotes` then `POST /v1/orders`	Pay across borders →
balance	balance	Exchange — convert between two currencies you hold	`POST /v1/quotes` then `POST /v1/orders`	Exchange →
balance	rail	Withdraw — a stand-alone payout from your balance	`POST /v1/withdrawals`	Withdraw →

Settlement between the two legs is handled internally and never appears in your request. You describe the two ends; the platform routes the middle.

The one rule that catches people out

A balance only exists for currencies the platform can hold. That is 14 of them — AVAX BNB BTC CUSD ETH EUR GBP POL SOL TRX USD USDC USDT XRP.

The other 17 collection currencies — ARS BOB BRL BWP CLP COP KES MWK MXN NGN RWF TWD TZS UGX XAF XOF ZMW — are collect-and-convert only. There is no ARS balance to credit, so POST /v1/deposits does not apply to them. You collect them as the origin leg of an order, which converts in the same operation.

Rule of thumb: can you hold it? Yes → a deposit is available. No → use an order and convert it on the way in.

1 · Collect into a balance

rail → balance. A deposit hands the payer instructions, waits for the money, and credits your balance in the same currency. Available for the 14 currencies you can hold — pick yours below for the request, the response to expect, and the sandbox simulation.

userData identifies the payer. For an individual, firstName, userEmail and country are required; add businessName for a business and the type is inferred. Corridors that verify identity need more — discover a corridor’s intake with GET /v1/currencies/{currency}/identity-schema?direction=payin&entityType=individual.

AVAX crypto · no payer identity

1 · Ask for instructions. rail: Required. One of AVALANCHE — it selects the network the payer sends on.

POST /v1/deposits — collect AVAX

{
  "currency": "AVAX",
  "rail": "AVALANCHE",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

2 · What comes back. depositInfo.depositType is CRYPTO — an address on the network you chose. Send the payer there.

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "AVAX",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "CRYPTO",
    "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "network": "AVALANCHE"
  }
}

3 · Simulate the payer in sandbox. Crypto uses fromAddress; sending counterparty is rejected.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "fromAddress": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
}

The deposit moves Pending → Received, the AVAX balance is credited, and deposit_completed fires.

BNB crypto · no payer identity

1 · Ask for instructions. rail: Required. One of BSC — it selects the network the payer sends on.

POST /v1/deposits — collect BNB

{
  "currency": "BNB",
  "rail": "BSC",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

2 · What comes back. depositInfo.depositType is CRYPTO — an address on the network you chose. Send the payer there.

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "BNB",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "CRYPTO",
    "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "network": "BSC"
  }
}

3 · Simulate the payer in sandbox. Crypto uses fromAddress; sending counterparty is rejected.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "fromAddress": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
}

The deposit moves Pending → Received, the BNB balance is credited, and deposit_completed fires.

BTC crypto · no payer identity

1 · Ask for instructions. rail: Required. One of BTC — it selects the network the payer sends on.

POST /v1/deposits — collect BTC

{
  "currency": "BTC",
  "rail": "BTC",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

2 · What comes back. depositInfo.depositType is CRYPTO — an address on the network you chose. Send the payer there.

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "BTC",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "CRYPTO",
    "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "network": "BTC"
  }
}

3 · Simulate the payer in sandbox. Crypto uses fromAddress; sending counterparty is rejected.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "fromAddress": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
}

The deposit moves Pending → Received, the BTC balance is credited, and deposit_completed fires.

CUSD crypto · no payer identity

1 · Ask for instructions. rail: Required. One of CELO — it selects the network the payer sends on.

POST /v1/deposits — collect CUSD

{
  "currency": "CUSD",
  "rail": "CELO",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

2 · What comes back. depositInfo.depositType is CRYPTO — an address on the network you chose. Send the payer there.

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "CUSD",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "CRYPTO",
    "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "network": "CELO"
  }
}

3 · Simulate the payer in sandbox. Crypto uses fromAddress; sending counterparty is rejected.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "fromAddress": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
}

The deposit moves Pending → Received, the CUSD balance is credited, and deposit_completed fires.

ETH crypto · no payer identity

1 · Ask for instructions. rail: Required. One of ETH — it selects the network the payer sends on.

POST /v1/deposits — collect ETH

{
  "currency": "ETH",
  "rail": "ETH",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

2 · What comes back. depositInfo.depositType is CRYPTO — an address on the network you chose. Send the payer there.

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "ETH",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "CRYPTO",
    "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "network": "ETH"
  }
}

3 · Simulate the payer in sandbox. Crypto uses fromAddress; sending counterparty is rejected.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "fromAddress": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
}

The deposit moves Pending → Received, the ETH balance is credited, and deposit_completed fires.

EUR fiat · payer identity required

1 · Ask for instructions. rail: Optional. Omit it and the platform selects this currency’s collection rail. Discover the available payin methods with GET /v1/currencies/EUR/payin-schema. This is the one currency where omitting amount is allowed (an open-amount collection); every other currency requires it.

POST /v1/deposits — collect EUR

{
  "currency": "EUR",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

2 · What comes back. depositInfo carries the pay-in instructions in the shape this currency’s rail uses. Give the payer both the account details and the referenceCode — the reference is how the inbound transfer is matched back to this deposit.

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "EUR",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "SEPA",
    "accountHolder": "VirtuaBroker",
    "iban": "ES9121000418450200051332",
    "bic": "CAIXESBBXXX",
    "bankName": "Example Bank",
    "amount": 1000,
    "referenceCode": "VB-8F3K2P"
  }
}

3 · Simulate the payer in sandbox. Fiat uses counterparty; sending fromAddress is rejected. EUR requires iban alongside name.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "counterparty": {
    "name": "Payer Name",
    "iban": "ES9121000418450200051332"
  }
}

The deposit moves Pending → Received, the EUR balance is credited, and deposit_completed fires.

GBP fiat · payer identity required

POST /v1/deposits — collect GBP

{
  "currency": "GBP",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "GBP",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "GBP_BANK_TRANSFER",
    "accountHolder": "VirtuaBroker",
    "accountNumber": "12345678",
    "sortCode": "040075",
    "bankName": "Example Bank",
    "amount": 1000,
    "referenceCode": "VB-8F3K2P"
  }
}

3 · Simulate the payer in sandbox. Fiat uses counterparty; sending fromAddress is rejected. GBP requires accountNumber alongside name.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "counterparty": {
    "name": "Payer Name",
    "accountNumber": "12345678"
  }
}

The deposit moves Pending → Received, the GBP balance is credited, and deposit_completed fires.

POL crypto · no payer identity

1 · Ask for instructions. rail: Required. One of MATIC — it selects the network the payer sends on.

POST /v1/deposits — collect POL

{
  "currency": "POL",
  "rail": "MATIC",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

2 · What comes back. depositInfo.depositType is CRYPTO — an address on the network you chose. Send the payer there.

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "POL",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "CRYPTO",
    "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "network": "MATIC"
  }
}

3 · Simulate the payer in sandbox. Crypto uses fromAddress; sending counterparty is rejected.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "fromAddress": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
}

The deposit moves Pending → Received, the POL balance is credited, and deposit_completed fires.

SOL crypto · no payer identity

1 · Ask for instructions. rail: Required. One of — it selects the network the payer sends on.

POST /v1/deposits — collect SOL

{
  "currency": "SOL",
  "rail": "",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

2 · What comes back. depositInfo.depositType is CRYPTO — an address on the network you chose. Send the payer there.

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "SOL",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "CRYPTO",
    "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "network": ""
  }
}

3 · Simulate the payer in sandbox. Crypto uses fromAddress; sending counterparty is rejected.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "fromAddress": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
}

The deposit moves Pending → Received, the SOL balance is credited, and deposit_completed fires.

TRX crypto · no payer identity

1 · Ask for instructions. rail: Required. One of TRON — it selects the network the payer sends on.

POST /v1/deposits — collect TRX

{
  "currency": "TRX",
  "rail": "TRON",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

2 · What comes back. depositInfo.depositType is CRYPTO — an address on the network you chose. Send the payer there.

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "TRX",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "CRYPTO",
    "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "network": "TRON"
  }
}

3 · Simulate the payer in sandbox. Crypto uses fromAddress; sending counterparty is rejected.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "fromAddress": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
}

The deposit moves Pending → Received, the TRX balance is credited, and deposit_completed fires.

USD fiat · payer identity required

POST /v1/deposits — collect USD

{
  "currency": "USD",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "USD",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "ACH_US",
    "beneficiaryName": "VirtuaBroker",
    "routingNumber": "021000021",
    "accountNumber": "1234567890",
    "bankName": "Example Bank",
    "amount": 1000,
    "referenceCode": "VB-8F3K2P"
  }
}

3 · Simulate the payer in sandbox. Fiat uses counterparty; sending fromAddress is rejected. USD requires accountNumber alongside name.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "counterparty": {
    "name": "Payer Name",
    "accountNumber": "12345678"
  }
}

The deposit moves Pending → Received, the USD balance is credited, and deposit_completed fires.

USDC crypto · no payer identity

1 · Ask for instructions. rail: Required. One of ARBITRUM BASE BSC ETH MATIC — it selects the network the payer sends on.

POST /v1/deposits — collect USDC

{
  "currency": "USDC",
  "rail": "ARBITRUM",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

2 · What comes back. depositInfo.depositType is CRYPTO — an address on the network you chose. Send the payer there.

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "USDC",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "CRYPTO",
    "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "network": "ARBITRUM"
  }
}

3 · Simulate the payer in sandbox. Crypto uses fromAddress; sending counterparty is rejected.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "fromAddress": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
}

The deposit moves Pending → Received, the USDC balance is credited, and deposit_completed fires.

USDT crypto · no payer identity

1 · Ask for instructions. rail: Required. One of BSC ETH MATIC TRON — it selects the network the payer sends on.

POST /v1/deposits — collect USDT

{
  "currency": "USDT",
  "rail": "BSC",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

2 · What comes back. depositInfo.depositType is CRYPTO — an address on the network you chose. Send the payer there.

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "USDT",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "CRYPTO",
    "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "network": "BSC"
  }
}

3 · Simulate the payer in sandbox. Crypto uses fromAddress; sending counterparty is rejected.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "fromAddress": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
}

The deposit moves Pending → Received, the USDT balance is credited, and deposit_completed fires.

XRP crypto · no payer identity

1 · Ask for instructions. rail: Required. One of XRP — it selects the network the payer sends on.

POST /v1/deposits — collect XRP

{
  "currency": "XRP",
  "rail": "XRP",
  "amount": 1000,
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES"
  }
}

2 · What comes back. depositInfo.depositType is CRYPTO — an address on the network you chose. Send the payer there.

201 · response

{
  "depositId": "dep_8f0c1b2a3d4e",
  "status": "Pending",
  "currency": "XRP",
  "expectedAmount": 1000,
  "amount": 0,
  "depositInfoPending": false,
  "depositInfo": {
    "depositType": "CRYPTO",
    "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "network": "XRP"
  }
}

3 · Simulate the payer in sandbox. Crypto uses fromAddress; sending counterparty is rejected.

POST /v1/simulate/incoming-transfer/deposit

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "scenario": "success",
  "fromAddress": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
}

The deposit moves Pending → Received, the XRP balance is credited, and deposit_completed fires.

When depositInfoPending is true the instructions are still being provisioned. Poll the deposit or wait for deposit_method_activated before showing anything to the payer. Each card’s step 3 simulates the payer in sandbox — the full contract is in Sandbox & simulation.

2 · Pay across borders

rail → rail. One order collects in the origin currency, converts at a locked rate, and pays the beneficiary in the destination currency. This is the flow for all 17 collect-only currencies, and the one to use whenever origin and destination differ.

1 · Lock a rate. A quote fixes the rate and fees for a short window.

POST /v1/quotes

{
  "originCurrency": "EUR",
  "destinationCurrency": "BRL",
  "originAmount": 5000
}

2 · Create the order. An order carries three objects — who pays, who receives, and where the money lands:

Field	Who / what	When you need it
`userData`	The payer — whoever sends the origin funds	Whenever the origin is a rail. Not needed when the origin rail is `BALANCE`, since you are the payer.
`destinationUserData`	The beneficiary — whoever receives the payout	Whenever the payout corridor requires beneficiary identity. Distinct from `destinationTransferData`: this is who they are, not where the money goes.
`destinationTransferData`	The payout instrument — account, wallet or phone number	Always. Its `type` is the rail; see the rail reference for its fields.

Both identity objects use the same shape. For an individual, firstName, userEmail and country are required. For a business, add businessName — supply it and the type is inferred, so you never send userType yourself. Everything else (lastName, address, city, postalCode, state, taxId, dob, phoneNumber) is optional to the schema, but individual corridors require more — a SEPA payout wants the beneficiary’s city and postalCode, and Brazilian payouts want a taxId. Send the fullest identity you hold.

POST /v1/orders

{
  "quoteId": "d290f1ee-6c54-4b01-90e6-d701748f0851",
  "userData": {
    "firstName": "Lucía",
    "lastName": "García",
    "userEmail": "payer@example.com",
    "country": "ES",
    "address": "Calle Gran Via 12",
    "city": "Madrid",
    "postalCode": "28013",
    "taxId": "12345678Z"
  },
  "destinationUserData": {
    "firstName": "Maria",
    "lastName": "Perez",
    "userEmail": "beneficiary@example.com",
    "country": "BR",
    "city": "São Paulo",
    "postalCode": "01310-100",
    "taxId": "123.456.789-00"
  },
  "destinationTransferData": {
    "type": "PIX_BR",
    "destinationName": "Maria Perez",
    "destinationPixCode": "supplier@example.com",
    "destinationTaxId": "123.456.789-00"
  },
  "externalReference": "invoice-8842"
}

A business payer looks the same with businessName added: { "businessName": "Acme SL", "firstName": "Lucía", "userEmail": "…", "country": "ES" }. firstName stays required — it identifies the representative.

3 · What comes back. The order embeds a deposit for its origin leg — the same depositInfo shape as a stand-alone collection. That is what the payer pays.

201 · response

{
  "orderId": "A7K9DP2X4Q1M",
  "status": "Pending",
  "deposit": {
    "depositId": "dep_11223344",
    "currency": "EUR",
    "expectedAmount": 5000,
    "depositInfo": {
      "depositType": "SEPA",
      "iban": "ES9121000418450200051332",
      "referenceCode": "VB-8F3K2P"
    }
  }
}

4 · Simulate the payer in sandbox. Keyed by orderId. The payer field follows the origin currency — per-currency values are in the origin reference, and the scenarios in Sandbox & simulation.

POST /v1/simulate/incoming-transfer/order

{
  "orderId": "A7K9DP2X4Q1M",
  "amount": 5000,
  "scenario": "success",
  "counterparty": {
    "name": "Payer Name",
    "iban": "ES9121000418450200051332"
  }
}

The order advances Pending → Processing → Success as the funds arrive, convert and pay out. Track it with order_status_updated.

3 · Exchange

balance → balance. Convert between two currencies you already hold. Same quote-then-order pair as a cross-border payment, but both legs are BALANCE, so there is no payer and no beneficiary — and nothing to simulate.

POST /v1/quotes

{
  "originCurrency": "EUR",
  "originRail": "BALANCE",
  "destinationCurrency": "USDC",
  "destinationRail": "BALANCE",
  "originAmount": 1000
}

POST /v1/orders

{
  "quoteId": "d290f1ee-6c54-4b01-90e6-d701748f0851",
  "destinationTransferData": { "type": "BALANCE" }
}

Because the funds are already held, the order settles without waiting for an inbound transfer. userData is not required when the origin rail is BALANCE.

4 · Withdraw

balance → rail. Pay out from a balance with no conversion. Use this instead of an order when the currency you hold is the currency you are sending. destinationTransferData takes the same rails and fields as an order’s payout leg — see the rail reference.

POST /v1/withdrawals

{
  "currency": "EUR",
  "amount": 1000,
  "destinationTransferData": {
    "type": "SEPA",
    "destinationName": "Maria Perez",
    "iban": "ES9121000418450200051332",
    "country": "ES"
  }
}

Reference · Sandbox & simulation

On non-production environments you never wire real money. You tell the platform the payment arrived, and the flow advances exactly as it would in production. Every collect card in section 1 carries the exact body for its currency, and section 2 shows the order variant — this is the contract behind them.

Which endpoint

Pick by what you are funding. You never declare the rail: it is derived from the resource’s own currency.

Funding	Endpoint	Keyed by
A stand-alone deposit	`POST /v1/simulate/incoming-transfer/deposit`	`depositId`
An order’s origin leg	`POST /v1/simulate/incoming-transfer/order`	`orderId`

Which payer field

The origin currency decides this, and sending the wrong one is rejected rather than ignored:

Fiat origin → counterparty, always with name, plus the instrument that currency’s real rail would carry. Per-currency values are in the origin reference.
Crypto origin → fromAddress. Sending counterparty is rejected.

POST /v1/simulate/incoming-transfer/order — fiat origin

{
  "orderId": "A7K9DP2X4Q1M",
  "amount": 5000,
  "scenario": "success",
  "counterparty": {
    "name": "Payer Name",
    "iban": "ES9121000418450200051332"
  }
}

POST /v1/simulate/incoming-transfer/deposit — crypto origin

{
  "depositId": "dep_8f0c1b2a3d4e",
  "amount": 1000,
  "fromAddress": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
}

Scenarios

scenario drives what happens after the funds land. It applies to fiat origins; crypto origins always settle as received.

`scenario`	Effect
`success` default	Full amount received; the deposit or order runs through to completion.
`failed`	The inbound transfer fails and the resource terminalizes.
`compliance_review`	Funds are held for review — the deposit stays under review with amount `0` until cleared.
`processing`	The inbound is accepted but stays in flight, so you can exercise your pending-state handling.

Send amount equal to the expected amount for a clean success. A smaller value exercises partial-payment handling and fires deposit_partially_completed instead. These endpoints exist only on non-production environments and must be enabled for your workspace.

Reference · Origin currencies

Everything you can collect, and how. Balance decides whether a stand-alone deposit is possible; the last column is the payer field the sandbox simulation requires alongside name.

Currency	Kind	Balance	Stand-alone collect	Simulate payer field
`ARS`	fiat	no	not available	`accountNumber`
`AVAX`	crypto	yes	`POST /v1/deposits`	`fromAddress`
`BNB`	crypto	yes	`POST /v1/deposits`	`fromAddress`
`BOB`	fiat	no	not available	none
`BRL`	fiat	no	not available	`pixKey` or `taxId`
`BTC`	crypto	yes	`POST /v1/deposits`	`fromAddress`
`BWP`	fiat	no	not available	`mobileMoneyNumber`
`CLP`	fiat	no	not available	none
`COP`	fiat	no	not available	`accountNumber`
`CUSD`	crypto	yes	`POST /v1/deposits`	`fromAddress`
`ETH`	crypto	yes	`POST /v1/deposits`	`fromAddress`
`EUR`	fiat	yes	`POST /v1/deposits`	`iban`
`GBP`	fiat	yes	`POST /v1/deposits`	`accountNumber`
`KES`	fiat	no	not available	`mobileMoneyNumber`
`MWK`	fiat	no	not available	`mobileMoneyNumber`
`MXN`	fiat	no	not available	`clabe`
`NGN`	fiat	no	not available	`mobileMoneyNumber`
`POL`	crypto	yes	`POST /v1/deposits`	`fromAddress`
`RWF`	fiat	no	not available	`mobileMoneyNumber`
`SOL`	crypto	yes	`POST /v1/deposits`	`fromAddress`
`TRX`	crypto	yes	`POST /v1/deposits`	`fromAddress`
`TWD`	fiat	no	not available	none
`TZS`	fiat	no	not available	`mobileMoneyNumber`
`UGX`	fiat	no	not available	`mobileMoneyNumber`
`USD`	fiat	yes	`POST /v1/deposits`	`accountNumber`
`USDC`	crypto	yes	`POST /v1/deposits`	`fromAddress`
`USDT`	crypto	yes	`POST /v1/deposits`	`fromAddress`
`XAF`	fiat	no	not available	`mobileMoneyNumber`
`XOF`	fiat	no	not available	`mobileMoneyNumber`
`XRP`	crypto	yes	`POST /v1/deposits`	`fromAddress`
`ZMW`	fiat	no	not available	`mobileMoneyNumber`

Reference · Payout rails

Each rail is a value for destinationTransferData.type, used identically by an order and a withdrawal. The type alone decides the field set — it never depends on where the money came from. Expand one for its copy-paste snippet and accepted formats.

ACH_US origin & destination · USD

Payout method achUS. Discover these fields at runtime with GET /v1/currencies/USD/destination-schema.