Skip to main content
For developers. Fiat access is gated: it is the second phase of institutional onboarding and is not automatic after KYB. For positioning, the access gates, onboarding, and how to apply, see the On/Off-Ramp overview.
All fiat operations run at the partner’s main account, over v4 endpoints, in both directions: fiat in to crypto out, and crypto back to EUR. Each direction pairs a fiat leg with a conversion step and a crypto leg.

Prerequisites

  • Completed institutional onboarding with approved fiat access — a separate, non-automatic phase after KYB; see How to get started on the overview page.
  • Per-account enablement gates — the fiat deposit invoice endpoint, dedicated deposit addresses, and Express Withdraw are enabled per account; confirm each with the account manager.
  • API accessHMAC-signed requests on the main account.
Since December 30, 2024, EEA accounts cannot deposit, withdraw, or create WhiteBIT Codes in USDT under MiCA. Use USDC or EURI for the crypto leg — see Regulatory Compliance.

On-ramp flow: fiat in, crypto out

The fiat-deposit-url endpoint works on demand. Contact WhiteBIT support and provide the API key to get access to the functionality. Without activation, the endpoint returns a permission error.
Generate a deposit invoice with a client-side uniqueId (any string up to 255 characters). The ticker must be a fiat currency with can_deposit: true, and the provider value comes from the Asset Status response — see the provider glossary entry:
For Go and PHP examples, see SDKs. The signing process is documented in Private HTTP API authentication. Operational rules for the deposit leg:
  • SEPA payment reference. The uniqueId must appear in the SEPA payment-reference field of the bank transfer. If the end user omits or alters it, the deposit may settle unmatched and require manual reconciliation through institutional support — see SEPA payment reference.
  • Redirect links. successLink and failureLink require feature activation through WhiteBIT support, which validates the destination domain; returnLink needs no activation.
  • Card flows. Card funding (the VISAMASTER provider) requires a customer billing block, and the browser must send the Referer header when opening the invoice link — messengers and email clients often strip it. See Card-provider flows.
  • Web-only currencies. Not every fiat ticker is depositable via API; confirm can_deposit in the Asset Status response before generating an invoice, and route unsupported tickers through the WhiteBIT web interface.
To complete the on-ramp, reach the currency for the crypto withdrawal through Convert where a conversion is needed: request a quote via POST /api/v4/convert/estimate, then execute it with POST /api/v4/convert/confirm before the quote expires. Honor the per-quote expiry returned in the response rather than assuming a fixed window. The convert service routes balances internally; no manual transfers between Main and Trade balances are required. The conversion pairs available to the account — including whether a fiat balance converts directly — are confirmed with the account manager. The crypto withdrawal step is documented in Crypto Withdrawals; for EEA accounts the crypto withdrawal carries a Travel Rule payload — see Travel Rule.

Off-ramp flow: crypto in, fiat out

Receive the crypto leg on a deposit address of the main account; dedicated per-transaction addresses via /create-new-address require per-account permission from support@whitebit.com. Inbound deposits for EEA and Turkey accounts are held until Travel Rule verification completes — see Travel Rule. For the fiat leg, choose the fee semantics: POST /api/v4/main-account/withdraw treats amount as including the fee, while POST /api/v4/main-account/withdraw-pay charges the fee on top so the recipient receives the specified amount. Fiat withdrawals require a beneficiary object; the required sub-fields vary by ticker and provider, so verify the current contract on the Create Withdraw Request reference before integration. A customerIp field is additionally required for USD or EUR with the VISAMASTER provider. The EUR SEPA IBAN example below uses the SEPA_BCB_GROUP provider, one of the SEPA/bank-rail providers (SEPA, SEPA_CLEAR_JUNCTION, SEPA_BCB_GROUP, FINCI, ZEN, BANKING_CIRCLE) that requires a top-level bankBic field carrying the beneficiary bank’s BIC/SWIFT code; the active provider for the account is confirmed via the Asset Status endpoint or the account manager. An EUR IBAN transfer (SEPA) request body:
  • Partial withdrawals. partialEnable: true raises the maximum limit for fiat withdrawals; the application must then handle the Partially successful status (18) and reconcile requestAmount against processedAmount in the history record.
  • KYC. Fiat withdrawals require KYC verification. In exceptional, documented cases the institutional team can arrange a per-account override — see Fiat withdrawal.
Withdrawals are irreversible once processed. Validate the destination details and amounts before submitting, and test the flow with minimum amounts first — no public testnet or sandbox is available.

Reconciliation and monitoring

Webhooks are the primary channel: verify the domain, then configure the webhook URL in the API key settings — see Webhooks for the setup flow. Verify the HMAC-SHA512 signature on every delivery using the X-TXC-APIKEY, X-TXC-PAYLOAD, and X-TXC-SIGNATURE headers, and track the strictly increasing nonce in each payload. Delivery is retried a small number of times spaced roughly an hour apart over a window of about one day; treat the cadence as best-effort. There is no webhook replay mechanism, so pair webhooks with polling: query POST /api/v4/main-account/history (transactionMethod: 1 for deposits, 2 for withdrawals) on a regular cycle and deduplicate against received events. The reconciliation pattern in the Payment Integration guide walks through the full loop. The identifier appears under different names across the API surface: Mark transactions complete only at terminal statuses: 3/7 for success, 4/9 for canceled deposits, 4 for canceled withdrawals. Platform availability is published at status.whitebit.com; per-asset deposit and withdrawal availability is reported by the Asset Status endpoint.

Failure and exception paths

Build handling for each of these before go-live:

What’s next

On/Off-Ramp FAQ

Activation, SEPA matching, fee semantics, reconciliation, and compliance questions.

Payment Integration

Endpoint-level lifecycle reference: statuses, fees, fiat operations, refunds.

Go-Live Checklist

Pre-production readiness verification for keys, webhooks, and compliance.