Crypto-as-a-Service FAQ

Answers to common questions about WhiteBIT Crypto-as-a-Service (CaaS).

​

Scope and model

​

What CaaS includes

CaaS covers a deposit address per end user, crypto payouts, and conversion with Convert, run from the partner’s own WhiteBIT account and offered under the partner’s own brand; fiat is added after fiat onboarding. See the CaaS overview.

​

Account model

CaaS runs on the partner’s own WhiteBIT account: the partner issues a deposit address per end user and keeps an end-user ledger. See Integration models and Verification split.

​

CaaS, sub-accounts, and Fast API Key

Sub-accounts and Fast API Key are separate from CaaS: a sub-account per end user under the partner’s account is Model A, used by Wallet-as-a-Service and Embedded Trading, and a partner-scoped API key on an end user’s own WhiteBIT account is Fast API Key via OAuth. See Integration models.

​

End-customer capabilities

End customers can create crypto wallets, store crypto in institutional custody, buy and sell with fiat, and send and receive crypto. See What end customers can do.

​

Deposit addresses

​

Crypto deposit enablement

The partner’s main account accepts crypto deposits after onboarding. Issuing a deposit address per end user uses create-new-address, which the account manager enables on request. See the Integration guide.

​

Address limits

Each create-new-address call creates a new address, within a per-currency address limit, so store every address against its end user. The account manager can discuss and adjust the limit for the account. See Address issuance and end-user mapping.

​

Memo networks

On memo networks, store the memo together with the address, show both exactly as issued, and match each deposit by address plus memo. See the Integration guide.

​

End-user offboarding

When an end user leaves the service, allow a reasonable period to withdraw or convert the end user’s crypto, then convert what remains and credit the proceeds to the end user in the partner ledger. The API provides no way to close or deactivate an issued deposit address, so keep the address mapped to the end user. See End-user offboarding.

​

Deposits and reconciliation

​

When to credit an end user

Credit an end user on the deposit.processed webhook, or a successful status in the history; deposit.accepted and deposit.updated report progress only. Part of a new deposit can stay held until the network fully confirms it — see Held deposits and Deposits and crediting.

​

Missed webhooks

Webhooks have no replay. Page the deposit and withdrawal history on a schedule and match the records locally against the stored addresses. See Operating the integration.

​

Held deposits

Part of a new deposit can stay held until the network fully confirms it. Withdrawals cannot draw on held funds, and the withdrawable balance reports the hold for the whole account, not for each end user. See Deposits and crediting.

​

Travel Rule holds

For EEA and Turkey accounts, inbound crypto deposits are held until Travel Rule verification completes, and no webhook reports these status changes. See Travel Rule holds on deposits.

​

Payouts and fees

​

Fee-inclusive and fee-on-top withdrawals

/withdraw deducts the fee from the amount, so the recipient receives the amount minus the fee; /withdraw-pay sends the exact amount and charges the fee on top. See Payouts.

​

Transfers between the partner’s end users

Settle a transfer between two of the partner’s end users in the partner ledger: the withdrawal endpoint rejects a withdrawal to one of the account’s own deposit addresses. See Payouts.

​

Withdrawal IDs

Store each payout’s withdrawal ID before sending the request, and never use one ID for two payouts. See Operating the integration.

​

Onboarding and access

​

Onboarding phases

Institutional onboarding has two phases: Phase 1 grants crypto operations access after KYC of the director or responsible person and KYB of the company; optional Phase 2 adds fiat access (Fiat access via SEPA). See Institutional Onboarding.

​

Fiat access via SEPA

Fiat access is added in Phase 2 of institutional onboarding and runs through the partner’s WhiteBIT account: SEPA withdrawals, and API-generated EUR deposit invoices once the account manager enables the invoice endpoint. See the On/Off-Ramp guide.

​

Crypto Lending access

Fixed and Flex lending endpoints are restricted to B2B partners and return a permission error until access is granted. Request access through the account manager. See Crypto Lending.

​

API base URL and regions

The global REST base URL is listed in the Partner FAQ; the regional environment is confirmed during onboarding.

​

Test environment availability

WhiteBIT does not offer a public testnet or sandbox — see the Partner FAQ and the Go-Live Checklist.

​

Rate limits

Rate limits are set per scope and per endpoint rather than as a single global value. See the Partner FAQ and Rate limits.

​

Security and compliance

​

Security certifications

WhiteBIT’s security certifications are listed in Regulatory Compliance; custody is described under Security and compliance.

​

Verification split

The partner verifies its own end users; WhiteBIT verifies the partner during institutional onboarding (KYB). See Integration models. In the European Union, a separate onboarding process and separate rules apply.

​

MiCA and Travel Rule for EEA end users

For EEA users, MiCA restricts some stablecoin operations — USDT deposits, withdrawals, and WhiteBIT Codes are unavailable, and USDC and EURI are the documented alternatives. The Travel Rule governs crypto transfers for EEA and Turkey accounts. See Regulatory Compliance and Travel Rule.

​

Restricted jurisdictions

Which jurisdictions are restricted or prohibited for the partner and its end customers is confirmed case by case with compliance@whitebit.com; bring the target regions to the first onboarding conversation so the applicable regime (including MiCA and Travel Rule scope) can be assessed. See Restricted jurisdictions.

​

Data Processing Agreement

A Data Processing Agreement (DPA) is available on request; WhiteBIT processes data in the European Union. Request it via compliance@whitebit.com. See Regulatory Compliance.

​

Support

​

Support contacts

The assigned account manager is the primary contact. Programs and onboarding go to institutional@whitebit.com; compliance, VASP, and DPA matters go to compliance@whitebit.com. Platform questions are answered at help.whitebit.com, and API documentation is on docs.whitebit.com.

​

What’s next