The problem: a deposit that lands late is a deposit that lands wrong
Funding speed is not a nice-to-have for a trading account. A trader sizes a position against the balance they expect to have, sends a top-up, and then needs that balance to be spendable before the market moves away from them. On a card or bank rail the money is in limbo for hours or days: authorized but not settled, sent but not arrived, with a status page that says "pending" and means nothing actionable. The trader cannot trade against limbo, so they either sit out the move or — worse — assume the funds are there and trip your risk checks.
The slow path also turns every deposit into a support conversation. "Did my transfer go through?" is the single most common ticket a funding desk handles, and it exists entirely because the trader and the broker are looking at different, lagging views of the same money. The trader sees a sent confirmation from their bank; the broker sees nothing yet; the deposit is somewhere in a settlement window neither of them controls. By the time it clears, the question has been asked three times and the trading moment has passed.
A crypto deposit collapses that window to the chain's own settlement time, and — just as important — gives both sides the same source of truth. The trader signs a transfer; the network confirms it; halfin tells your platform it confirmed. There is no acquirer settlement batch and no interbank delay between the trader's action and your credit. The deposit is either confirmed on-chain or it is not, and you find out the moment it is.
- A trader sizes a position against an expected balance — the deposit has to be spendable before the move, not after.
- Card and bank rails leave money in a settlement limbo neither the trader nor the broker can resolve.
- "Did my deposit go through?" is a funding desk's most common ticket, and it exists only because of lag.
- Crypto settles to the chain's own clock and gives trader and broker one shared confirmation signal.
Two funding paths: hosted checkout or a static deposit address
halfin gives you two ways to take a trader deposit, and they fit different moments in the relationship. A hosted checkout invoice is the right tool for a discrete, priced top-up: you state an amount, halfin renders a payment page with the exact figure, the network, and a countdown, and the trader pays that specific invoice. A static deposit address is the right tool for an ongoing relationship: each trader gets a persistent receive address tied to their account, and they fund it whenever they want, in whatever amount, as many times as they like — no new invoice per deposit.
Reach for hosted checkout when the deposit has a number attached and a window that matters: a margin call, a fixed top-up, a funding step you want anchored to a fiat figure. The invoice locks its rate at activation, shows the trader exactly what to send, and expires if it goes unpaid — so a stale quote never becomes a wrong-sized credit. Reach for a static address when the trader is a repeat depositor and you want zero friction on the second, fifth, and fiftieth top-up. The address does not change, the trader can save it, and every inbound transfer to it is detected, confirmed, and credited the same way.
Both paths land in the same place. Whether the funds arrive against a hosted-checkout invoice or against a static address, halfin applies the per-chain confirmation threshold, credits the deposit reorg-aware, and emits a signed webhook your backend reacts to. You do not build two crediting pipelines; you build one webhook handler and choose, per trader or per moment, which front door the deposit comes through.
| Funding path | Best for | What the trader does |
|---|---|---|
| Hosted checkout invoice | A discrete, priced top-up — margin call, fixed funding step, fiat-anchored amount | Pays one invoice for a shown amount on a halfin-hosted page with a countdown |
| Static deposit address | A repeat depositor you want to fund with zero per-deposit friction | Sends any amount to a persistent address tied to their account, any time |
What happens between "sent" and "spendable"
The value of a deposit primitive is in the part the trader never sees: turning a raw on-chain transfer into a balance you can safely let them trade against. A transfer appearing on the network is not yet money you should credit. halfin watches for the deposit, then waits for the chain's own confirmation threshold before it treats the funds as settled — the number of confirmations is set per chain, because a Bitcoin deposit and a fast-finality deposit do not carry the same reorganization risk.
Crediting is reorg-aware, and that distinction is the whole point on a funding desk. A naive integration that credits on the first sighting of a transaction will, eventually, credit a deposit that a chain reorganization later unwinds — and a trader who has already opened a position against phantom margin is now a loss you cannot claw back cleanly. halfin only marks the deposit credited once it has held to the per-chain threshold, and reflects a reorg that removes a transaction rather than ignoring it. The balance you let a trader use is a balance that actually settled.
When the deposit clears, halfin fires an HMAC-signed webhook. That event — not a redirect, not a screenshot of a wallet, not the trader's word — is the signal to move their account balance. Verify the signature before you act on it, then credit the trader and let them trade. The webhook is the same shape whether the funds came through hosted checkout or a static address, so one verified handler drives both funding paths.
- A transfer on the network is not yet a credited balance — halfin waits the per-chain confirmation threshold first.
- Crediting is reorg-aware: a deposit that a chain reorg later unwinds is reflected, not silently honored.
- The credit signal is an HMAC-signed webhook — verify it before moving the trader's balance.
- Hosted checkout and static-address deposits emit the same event, so one handler covers both.
Which assets carry a fast deposit, and on which networks
For a trader top-up the practical asset is a dollar stablecoin, because the balance the trader funds and the balance they trade against should both be denominated the same way. A volatile native coin can move between the moment the trader sends it and the moment it confirms, leaving the credited amount different from what either of you expected. A stablecoin deposit keeps the funded figure stable across the confirmation window, which is exactly when a margin top-up cannot afford to drift.
halfin accepts USDT on Tron (TRC-20), on Ethereum (ERC-20), and on Solana, which together cover the markets where active traders most often hold value and want the lowest-friction transfer. USDC is accepted on Ethereum (ERC-20), on Base for low-cost settlement, and on Solana, which suits USD-native and EVM-first traders. Letting a trader fund from the chain they already use means the deposit does not stall on the trader having to acquire a new asset just to top up — the fastest deposit is the one the trader can send with the wallet already open on their phone.
The network the trader chooses sets the confirmation behavior, not the crediting logic. A Tron deposit and a Solana deposit reach the credited state on their own chains' terms, but they arrive at your webhook handler identically. You support the asset-and-network surface that fits your traders; halfin handles the per-chain differences underneath, and your platform sees one consistent "this trader's deposit is now spendable" event.
- Fund top-ups in a dollar stablecoin so the credited balance does not drift across the confirmation window.
- USDT on Tron, Ethereum, and Solana for the broadest active-trader reach.
- USDC on Ethereum, Base, and Solana for USD-native and EVM-first traders.
- The chosen network sets confirmation timing; your webhook handler sees one consistent credit event.
Wiring a fast deposit into your funding flow
There is no special "instant deposit" endpoint — speed comes from the rail, not a setting. A priced top-up is a fiat-anchored invoice you present on hosted checkout; a standing top-up channel is a static deposit address you create once and attach to the trader. In both cases the credit you care about is delivered the same way: an HMAC-signed webhook your backend verifies and then acts on. Your integration's real work is that handler, not the front door.
The request below creates a hosted-checkout deposit invoice for a $250 margin top-up. Send the amount as a string — monetary values are strings end to end — with the fiat currency as the anchor, and pass an idempotency key keyed to the trader and the attempt so a retried request returns the existing invoice instead of opening a duplicate. For a repeat depositor you would instead create a static deposit address once and skip the per-deposit call entirely. The exact response shapes for both live in the docs and the @halfin/sdk-merchant types.
# A $250 margin top-up as a hosted-checkout deposit invoice.
# amount_fiat + fiat_currency anchor the figure; the trader pays
# USDT, USDC, or a supported native asset on the hosted page.
curl -X POST https://api.thehalfin.com/api/v1/invoices \
-H "X-API-Key: $HALFIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"amount_fiat": "250.00",
"fiat_currency": "USD",
"deferred": true,
"description": "Margin top-up — trader_8821",
"idempotency_key": "deposit-trader_8821-attempt_1"
}'
# halfin locks the rate at activation and returns an invoice you
# present via hosted checkout. Credit the trader on the verified
# invoice.paid webhook — not on the redirect back from checkout.
# For a repeat depositor, create a static deposit address once
# instead. See docs.thehalfin.com for the full schemas.Where the deposit ends, and where the broker's systems take over
halfin's job stops at a credited, confirmed deposit. The trader's tradable balance, their margin, their open positions, and every risk decision downstream live in your platform — halfin does not see them and does not need to. Treat the signed credit webhook as the one trigger that moves the trader's account, keep your trading engine as the system of record, and you get fast funding without handing the chain explorer or the confirmation logic to your support desk.
The compliance boundary does not move just because the deposit is fast. Crypto funding still rides on your trader identity and screening work — KYB onboarding and AML awareness are process, not a status, and any market-specific obligations your brokerage holds remain yours. Keep trader KYC inside your stack, screen the depositing wallet before you credit, and keep every invoice, static-address deposit, and webhook record attached to the trader ID so finance can reconcile a balance change back to the on-chain transfer that caused it.
Fast deposits are one corner of the FX brokerage flow, and they connect to the rest. When a funded trader withdraws, that runs through halfin's payout primitives rather than this deposit path. When deposits arrive across several stablecoins and chains, balance conversion consolidates the mix into the asset you want to hold. The deposit is the entry point; withdrawals, treasury, and affiliate payouts sit alongside it in the broader FX brokerage hub.
- Move the trader's tradable balance on the verified credit webhook — your platform stays the system of record.
- KYB and AML are your process; screen the depositing wallet and keep records tied to the trader ID.
- Withdrawals use halfin payouts; balance conversion consolidates a multi-asset, multi-chain deposit inflow.
- Reconcile every balance change back to the on-chain transfer behind the invoice or static address.