Skip to main content
POST
Take a one-off bank deposit
Provider sandbox on this deployment. Our backend targets the bank provider’s sandbox: bank details are test details, no real transfer settles, and settlement lands on a testnet (read network from GET /v1/config). Known limits: only the EUR/IBAN rail is wired for the simulated pay-in, and identity checks run on test-mode applicants. Every response says which environment answered in its environment field.
Currently being connected, docs updating. This endpoint answers mock: true: ids, shapes and statuses are real and deterministic from your input, every money figure is the placeholder 1234567.89, and nothing is sent to a provider. Integrate against the shape; do not compute anything from the figures.

Authorizations

Authorization
string
header
required

Your API key, issued by us and shown once at creation.

Body

application/json
accountId
string
required

The user paying. Onboard them first (POST /v1/fiat/onboard).

Minimum string length: 1
Example:

"acct_8f2c91d0a4"

walletId
string
required

The registered wallet the settled stablecoin is delivered to (from onboarding).

Minimum string length: 1
Example:

"wlt_5b71e0c3"

fiatCurrency
string
required

ISO 4217 code the user pays in. Must be a currency the bank rails take (GET /v1/currencies, fiat); others are refused with no_route.

Pattern: ^[A-Za-z]{3}$
Example:

"EUR"

fiatAmount
string
required

What the user will send, decimal string in major units. The details are issued for this amount.

Pattern: ^\d+(\.\d+)?$
Example:

"500.00"

reference
string

Your idempotency key, up to 64 characters. A retry carrying the same value answers the original object instead of creating a second one.

Maximum string length: 64
Example:

"payout-2026-09-02-115"

Response

The details to show the payer.

environment
enum<string>
required

Which environment answered. sandbox: at least one money upstream is the provider's sandbox - no real money moves there, and the card corridor is the sandbox's asset (read GET /v1/config), not the documented production one. production: every configured upstream is real. Derived from the configured upstream hosts at boot, never a flag.

Available options:
sandbox,
production
Example:

"sandbox"

mock
boolean
required

Always true on this endpoint: the provider behind it is currently being connected, docs updating. Ids, shapes and statuses are real and deterministic from your input; every money figure is the placeholder 1234567.89; nothing is sent to a provider. The field disappears the day the provider is wired, so branch on its presence, not its value.

Example:

true

id
string
required

The deposit id. Poll it on POST /v1/bank/deposit/status.

Example:

"bdp_3a71f0c9e4d2b581"

details
object
required

The bank details to display, shaped by the rail (an iban and bic for SEPA, an accountNumber for account-number rails, a clabe for SPEI, a key for PIX), always with the beneficiary and the payment reference the transfer must carry. Render what comes back rather than assuming a shape. While the provider is being connected the details are self-labelled test values that accept nothing.

Example:
rail
string
required

The rail these details are on, as GET /v1/currencies names it.

Example:

"sepa"

expiresAt
string
required

ISO 8601. After this the details stop accepting money; a transfer already in flight still settles.

Example:

"2026-09-15T17:30:00.000Z"

status
enum<string>
required

awaiting_deposit on creation - the bank vocabulary GET /v1/statuses lists.

Available options:
awaiting_deposit,
funded