Skip to main content
Fees are configured by CBPay per service, country and asset. When nothing is configured for a combination, the fee is 0.

​
How payouts and payins are charged

FX pricing lives in your exchange rate: the rates you see in GET /v1/rates are your rates, and they are exactly the ones used at execution — no separate percentages. Each country carries both sides:
  • rate — the rate for your payouts (dispersals). If you disperse the equivalent of 100 USDT, you are debited 100 USDT plus the fixed fee (when configured for your account).
  • payin_rate — the rate for your payins (fiat collections/deposits). The credit is the local amount converted at that rate, minus the fixed fee (when configured for your account).
What the beneficiary receives (payout) or what you are credited (payin) depends on your account’s rates for that country. Quoted = charged, always.

​
Services with fixed or percent fees

For %-based services the formula is fee = ceil(amount × percent / 100) + fixed_amount (rounded up to the micro-USDT).
Standalone fixed charges (compliance, KYC/KYB verification, wallet creation and banking) are refunded automatically if the upstream operation fails (compliance_refund / verification_fee_refund / wallet_creation_refund / wallet_service_refund / banking_fee_refund).

​
Card payin settlement delay

Card collections can carry a settlement delay (settlement_hours, an integer number of hours; 0 = no delay — the default). With a delay configured, a confirmed card payment confirms the payin right away: the status becomes credited, the payin_credited webhook fires immediately, and a checkout link paid with card closes as paid. What waits is the balance: it lands in your ledger when the settlement runs — at settle_at (a worker settles due payins every minute) or earlier if your org admin releases it manually from the panel. While the balance is pending, the payin response (create, get and list) carries settle_at (RFC 3339) and settlement_pending: true; once the balance lands it carries settled_at instead. At confirmation the payin_settlement_scheduled webhook also fires exactly once (idempotent) with status: "credited", the scheduled amounts and settle_at, so your integration can tell “paid, balance scheduled” apart from “paid, balance already available”.
settle_at = created_at + settlement_hours — the delay counts from the payin creation (≈ when the charge is confirmed at the processor). A payin whose deadline has already passed by the time it is approved or assigned settles immediately (no settlement_pending). The automatic conversion (when configured) runs when the balance settles, not before.
A payin whose settlement is still pending cannot be refunded: the refund debits your balance and those funds are not released yet, so the request is declined with 422 settlement_pending. Wait for settle_at or ask your org admin to release the settlement first — then the refund works as usual.
The settlement delay is configured by CBPay on the payin_card fee of your account. Your confirmation signals are unchanged — payin_settlement_scheduled and payin_credited arrive at payment time; only the balance availability waits for settle_at.

​
Banking rail fees

Banking operations carry transactional fees in the operation currency (the BANK_USD / BANK_EUR balance the operation moves):
  • Deposits (banking_deposit): charged when the incoming deposit is credited, capped at the deposit amount (min(fee, amount)) — a small deposit never leaves a negative balance.
  • Transfers (banking_transfer_ach, banking_transfer_swift, banking_transfer_wire, banking_transfer_sepa): charged at dispatch; your available balance must cover amount + fee in the operation currency or the request is declined with 402 insufficient_funds. If the transfer is definitively rejected afterwards, the fee is refunded.
  • Fallback: a rail without its own configuration (neither on your account nor as a default) uses the legacy banking_operation fixed fee in USDT. A rail configured with 0% + 0 fixed is explicitly free — it does not fall back.
When a rail fee applies, the dispatch response exposes banking_fee and banking_fee_asset (the charged amount and its BANK_* currency), so each charge is attributable to its rail.

​
Internal transfers: always free

Transfers between CBPay accounts (POST /v1/transfers) carry no fee, regardless of the combination: person↔person, person↔company or company↔company. The money moves inside the ecosystem.

​
Your exchange rate

GET /v1/rates returns your account’s own exchange rate for each country — the same rates your operations execute at, no surprises: rate for payouts and payin_rate for payins (local_amount / rate = USDT).

​
Check your terms

GET /v1/rates returns, along with your rates, the fee configuration currently applied to your account:
asset_prices is the reference USD price of each virtual balance (to value them on screen) — it implies no conversion and no spread. The response also includes a settlement block with the effective price per asset if you pay operations from a balance other than USDT (money model): that price already includes the conversion margin, so what you see is what applies. The charged fee is always explicit in each operation’s response (fee field) and in the ledger.

​
Full example

A payout equivalent to 100 USDT with fixed_amount: "0.30":
The beneficiary receives the full local amount you specified; you are debited the equivalent at your rate plus the fixed fee. A payin equivalent to 100 USDT with fixed_amount: "0.30":
The payer pays the exact local amount you specified; you are credited the equivalent at your payin_rate minus the fixed fee.
Last modified on August 10, 2026