The problem: the deposit is the funnel, and cards leak it
A prop firm's product is the evaluation. Everything upstream — the marketing, the rules page, the dashboard — exists to get a trader to the moment they pay the challenge fee. That moment is also the most fragile step in the funnel, because it usually runs on a card rail that was never built for a one-off cross-border charge to a trading-adjacent merchant. The issuer flags it, the bank blocks it, or the trader simply does not have a card that works for this, and the funded account that would have generated activity never opens.
The traders most prop firms want are exactly the ones cards serve worst: international, mobile-first, paying outside their home banking hours, often already holding stablecoins because that is how they move money in their market. For them a card decline is not fraud and not a lost lead — it is a payment instrument that does not reach where they live. You see the abandoned checkout; you do not see that it abandoned at the card form, not at the price.
A stablecoin deposit removes the issuer from the path. The trader signs a transfer from a wallet they control, on a chain that settles the same way for everyone, with no acquirer coverage map and no cross-border decline code in between. The question stops being "will this trader's card authorize a charge to us" and becomes "does this trader hold a stablecoin" — and for the audience that funds challenges at odd hours from anywhere, that answer is increasingly yes.
- The challenge-fee step is where the funnel leaks, and cards leak it hardest for international traders.
- A cross-border card decline looks identical to a lost lead — you optimize the page, not the instrument.
- Your best-fit traders are mobile-first, often outside banking hours, and frequently already hold stablecoins.
- A stablecoin transfer has no issuer, no coverage map, and no cross-border decline path.
How halfin fits: a fiat-anchored deposit on hosted checkout
You do not price challenges in crypto. A $99 evaluation is a $99 evaluation whether the trader pays from Lagos, Lahore, or London. You send halfin the fiat amount and currency, and it quotes the equivalent in the stablecoins and native assets you accept, then locks that rate at activation. The trader is shown a concrete token amount and a payment window — not a number that drifts while they read your rules one more time.
The rate lock is what keeps a deposit page honest. Crypto prices move on a checkout timescale; if you quoted at draft time and the trader paid twenty minutes later, the token amount would no longer match the dollar fee you book. halfin freezes the quote when the invoice activates and stamps an expiry. Pay inside the window and the amount the trader was shown settles to exactly the fiat fee you priced. Let the window lapse and the invoice expires rather than silently re-pricing — the trader re-issues at the current rate, and your accounting never sees a deposit worth something other than the fee.
Present the deposit through hosted checkout so you render no payment UI of your own: the trader gets a halfin-hosted page with the address, the exact amount, the network, and a countdown. halfin applies the per-chain confirmation threshold, credits the deposit reorg-aware, and fires an HMAC-signed webhook the instant the invoice resolves. Verify the signature, then open the funded account. That confirmation event — not a redirect, not a card authorization — is the single signal that the challenge is paid.
| Stage of the deposit | What the trader sees | What you do |
|---|---|---|
| Invoice activated | A fixed token amount, the network, and a countdown on hosted checkout | Anchor the fee in fiat; the rate is locked for the payment window |
| Payment seen | Confirmation that the transfer is in flight | Wait — do not open the account yet; crediting is not final |
| Invoice paid | A paid state once confirmations meet the per-chain threshold | Verify the invoice.paid webhook signature, then fund the challenge account |
| Invoice expired | An expired page after the window lapses with no payment | Hand to dunning; the trader re-issues at the current rate |
Why stablecoins carry the deposit, and on which networks
For a challenge deposit the asset of choice is a dollar-denominated stablecoin, not a volatile native coin. The reason is the same one that makes fiat-anchored pricing work: the number you book and the number that lands on-chain are both dollars, so the trader pays a fee they understand and you reconcile against the figure you charged. A trader is buying an evaluation, not taking a position on a token between checkout and confirmation.
USDT carries the broadest reach in the markets where prop firms find traders and where cross-border cards fail most often; halfin accepts it on Tron (TRC-20), on Ethereum (ERC-20), and on Solana. USDC suits USD-native and EVM-first traders — those already on-chain or holding a dollar stablecoin in a treasury — and halfin accepts it on Ethereum as an ERC-20 token, on Base for low-cost settlement, and on Solana. Offering both across those networks means a trader almost anywhere can fund a challenge on a chain they already use rather than acquiring something new just to pay you.
A single deposit invoice can present the networks and assets you support, and the trader settles in whichever they hold — the fiat anchor is unchanged regardless of their choice. You are not maintaining a separate deposit flow per asset or per chain; one invoice draws from the real supported surface and the dollar fee stays put.
- Price in fiat, collect a dollar stablecoin — the trader funds a fee they understand.
- USDT on Tron, Ethereum, and Solana for the broadest cross-border trader reach.
- USDC on Ethereum, Base, and Solana for USD-native and EVM-first traders.
- One deposit invoice presents the supported assets; the dollar fee never moves with the choice.
Creating a challenge deposit with one API call
There is no special deposit endpoint and no per-region configuration. A challenge fee is a fiat-anchored invoice: send the amount and currency, let halfin quote and lock the payable asset amount, and present the hosted checkout. The trader's geography lives entirely in their wallet and their network choice, not in your integration.
The request below creates one deposit invoice against the public REST API. Pass an idempotency key keyed to the trader and the attempt so a retried request — a flaky connection from a distant region is exactly when retries happen — returns the existing invoice instead of opening a second one. The amount is a string, because monetary values are strings end to end, and the currency is your fiat anchor. The exact response shape lives in the docs and the @halfin/sdk-merchant types.
# Fund a $99 challenge: price in USD, settle in a stablecoin.
# amount_fiat + fiat_currency anchor the fee; the trader picks
# USDT, USDC, or a native asset at hosted checkout.
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": "99.00",
"fiat_currency": "USD",
"deferred": true,
"description": "Evaluation challenge — acct_4417",
"idempotency_key": "challenge-acct_4417-attempt_1"
}'
# halfin locks the rate at activation and returns an invoice you
# present via hosted checkout. Fund the account on the verified
# invoice.paid webhook. See docs.thehalfin.com for the full schema.Where the deposit ends, and where the firm's obligations begin
halfin funds the deposit; it does not become your trading operation. The challenge rules, the profit targets, the risk limits, the account state, and the decision to pass or fail a trader all live in your platform. halfin's role is narrow and clean: collect the stablecoin payment, apply the confirmation threshold, credit it reorg-aware, and tell you — via a signed webhook — that the fee landed. Treat that confirmation as the trigger to provision the funded account, and keep your own dashboard as the system of record for everything the trader does afterward.
The compliance boundary sits in the same place. Crypto deposits do not relax the identity and screening work a prop firm carries — KYB onboarding and AML awareness are process, not a status, and any market-specific obligations your program holds remain yours. Keep trader KYC and eligibility decisions inside your own stack, screen wallets and counterparties before you accept a deposit, and keep each invoice and webhook record attached to the trader ID so finance and support can reconcile a funded account back to the payment that opened it.
Two adjacent flows close the loop and live elsewhere in the FX cluster. When a funded trader withdraws a profit split, that runs through halfin's payout primitives — a single approved payout to the trader's wallet — not through this deposit path. And when deposits arrive across several stablecoins and chains, balance conversion lets you consolidate the mix into the asset you want to hold without moving funds off-platform. The deposit is the entry point; the rest of the FX brokerage hub ties withdrawals, affiliate payouts, and treasury together.
- Provision the funded account on the verified invoice.paid webhook, not on a redirect.
- Challenge rules, account state, and pass/fail stay in your platform — halfin only handles the payment.
- KYB and AML are your process; screen wallets and keep invoice records tied to the trader ID.
- Profit-split withdrawals use halfin payouts; balance conversion consolidates a multi-asset deposit inflow.