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.
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 access — HMAC-signed requests on the main account.
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.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:
- curl
- Python
- SEPA payment reference. The
uniqueIdmust 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.
successLinkandfailureLinkrequire feature activation through WhiteBIT support, which validates the destination domain;returnLinkneeds no activation. - Card flows. Card funding (the VISAMASTER provider) requires a
customerbilling block, and the browser must send theRefererheader 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_depositin the Asset Status response before generating an invoice, and route unsupported tickers through the WhiteBIT web interface.
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: trueraises the maximum limit for fiat withdrawals; the application must then handle thePartially successfulstatus (18) and reconcilerequestAmountagainstprocessedAmountin 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.
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 theX-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.