Two deadlines: the line moves, and the winner waits
Sports betting has a tighter clock than almost any other gaming vertical. A bettor who wants to back a team has a window — sometimes minutes before kickoff, sometimes seconds as a live line swings — and a deposit that stalls in that window is a bet that never gets placed. Card rails fail in exactly this window: gaming merchant categories draw declines and issuer holds, so the bettor stares at a generic decline they can't fix while the price they wanted disappears. The operator doesn't see a failed transaction; they see a bettor who didn't stake.
The other deadline is the payout. A winner who placed a bet on Saturday and is still waiting for their money on Tuesday is a churned customer and a bad review. For sportsbooks, payout speed is the single most-discussed feature in the communities your bettors live in — slow withdrawals get a book named and shamed, fast ones get it recommended. When winnings sit in a manual queue, the cost isn't just a support ticket; it's the next deposit that bettor won't make and the friend they won't refer.
Then there is settlement risk that card rails leave open. A card deposit can be reversed long after the event has played out and the bet has graded. The book has already paid the winner on a deposit that just evaporated. For a sportsbook running a high volume of small stakes, that friendly-fraud reversal is a structural leak — and it is precisely the leak crypto rails close, because a confirmed on-chain deposit is final.
Funding a bet: rate-locked, confirmed on-chain, credited once
A deposit for a sportsbook has to be predictable to the cent, because the bettor is funding against a stake they already have in mind. You create a fiat-anchored invoice for the amount the bettor chose — the credited value is pinned to a fiat figure, so a $40 deposit credits as $40 of balance regardless of how the asset's price drifts while they fund. The rate is locked at activation, not recalculated at confirmation, so a bettor who hesitates for a minute before sending doesn't get a different balance than the one they saw.
The bettor pays in the asset and network they already hold. A USDT-on-Tron bettor and a USDC-on-Solana bettor land on the same invoice; you don't force everyone onto one chain and lose the ones who hold the wrong asset. Stablecoins are the workhorse here precisely because the credited value doesn't move between the bet decision and the confirmation — the deposit is worth what the bettor expected when the line is still live.
Crediting is on-chain truth, not an optimistic UI. halfin applies each chain's confirmation threshold and credits reorg-aware, so a balance shown as funded has actually settled under that chain's rules. The instant it does, your server receives an HMAC-signed webhook — verify the signature, then credit the betting balance. Underpayment and overpayment are recorded explicitly against what was quoted, so a bettor who sends slightly too little surfaces as a clear mismatch instead of vanishing into a silent gap your reconciliation finds days later.
- Fiat-anchored invoice so a chosen stake credits at face value, not at a drifting market price.
- Rate locked at activation — a slow fund doesn't change the credited balance.
- Bettor pays from their own wallet on any network you accept; stablecoins keep the value stable.
- Reorg-aware crediting at the per-chain threshold, then an HMAC-signed webhook to your server.
- Underpaid and overpaid handled explicitly against the quote — no silent mismatches.
Paying the winner: a payout that goes out as the chain confirms
Settling winnings is the reverse of funding, and it's where a sportsbook earns its reputation. Your platform owns the decision — the bet has graded, KYC is clear, wagering and bonus rules are satisfied, fraud checks pass — and halfin owns the execution. Once your back office approves a cashout, you create a payout to the winner's wallet. Because payouts run on the same chains you accept deposits on, a bettor can withdraw to the wallet they funded from.
High payout speed here is structural, not a setting you toggle. There is no card issuer in the loop to decline an approved withdrawal the way a processor declines a refund, so an approved cashout goes out as fast as the chain confirms it. Each payout enters a pending-approval state and is released under operator review, so the high-throughput path your integration uses to stage winnings stays separate from the human control point that signs them off — nothing leaves the balance unattended.
Winnings settlement and treasury settlement are different jobs, and halfin separates them. An individual cashout to one winner is a single payout. The recurring runs around a sportsbook — weekly affiliate commissions, referral rebates, revenue-share to partners who send traffic — are a fan-out over the same single-payout API, each line carrying its own idempotency key so a retried run never double-pays. The payout.completed webhook is what moves the bettor balance and your treasury records; the dashboard is the human view, the webhook is the ledger's source of truth.
Throughput when everyone bets at once
Sportsbook load is not flat. It spikes hard around marquee events — a title fight, a derby, the final whistle of a tournament — when deposits and cashouts arrive in the same compressed window. The payment layer has to absorb that burst without becoming the bottleneck that loses the bettor who's trying to fund a live line. Two halfin properties matter most at peak.
First, deposits are independent per invoice. Each funding attempt is its own invoice on its own address with its own signed confirmation, so a thousand bettors funding at kickoff don't queue behind each other — there's no shared batch step that serializes them. Second, settlement after the event is a fan-out you can stage unattended: as bets grade and winners are approved, your integration creates payouts continuously, each idempotent, and you approve the run once rather than babysitting a row-by-row script while your support desk fills up.
The discipline that keeps a peak event sane is the same one that keeps a quiet Tuesday sane: signed events drive the ledger. A deposit credits a bettor only after you verify the webhook signature; a cashout updates the balance only on payout.completed. Under load, that means your automated balance logic trusts the same authoritative event it trusts at low volume — the checkout redirect a bettor sees is cosmetic, the signed webhook is what your system acts on.
No chargebacks on a graded bet
The single structural difference between card and crypto rails for a sportsbook is irreversibility. A confirmed on-chain deposit is final: a bettor cannot call their bank weeks after the event, dispute the deposit, and claw back a stake on a bet that already lost. For a book paying out winners against those deposits, that closes a fraud vector card processors leave open and price into gaming-MCC fees.
Irreversibility cuts both ways, and the honest framing matters. Because a confirmed deposit can't be reversed by the sender, a genuine mistake is corrected deliberately, not by a chargeback button. halfin's refunds primitive exists for exactly that — when you decide a deposit should be returned, you issue a refund as an explicit, operator-controlled action with its own record, rather than discovering a reversal after a bet has graded and a winner has been paid. You keep control of when money goes back; the bettor cannot force it.
The operational payoff is a cleaner ledger. Deposits that credit stay credited; cashouts that go out are recorded as payouts, not as refunds against a card. Reconciliation becomes matching signed events to bettor and treasury movements, instead of carrying a rolling reserve against reversals that may or may not arrive after every settled fixture.
Where the sportsbook stops and halfin starts
Sports betting is a regulated activity, and the regulation belongs to the operator. halfin is payment infrastructure — it does not issue betting licenses, does not give legal or licensing advice, and does not replace your obligations in the markets you serve. Whether a sportsbook may operate in a given jurisdiction is your question to answer with your own counsel and regulator. What halfin provides is process, not a certificate: operator onboarding runs through KYB, processing on the rails is AML-aware, and travel-rule expectations are something to design for as a process — none of it a status halfin holds on your behalf.
The clean division keeps both the integration and the compliance story sane. Your platform owns bettor identity, age and jurisdiction checks, responsible-gambling controls, the odds and grading engine, and the decision to accept a deposit or release a cashout. halfin receives the approved instruction, processes the rail, keeps the payment record, and returns signed status your finance and compliance teams reconcile. Bettor KYC stays your system of record; invoices, payouts, and webhooks attach to your bettor IDs for your own controls.
Below is the deposit call a sportsbook makes to fund a bettor. Create a fiat-anchored invoice for the amount the bettor chose, redirect them to the hosted checkout URL in the response, and wait for the signed invoice.paid webhook before crediting the betting balance. The full request and response schema lives at docs.thehalfin.com.
- Operator onboarding via KYB; halfin knows the book it processes for.
- AML-aware processing and travel-rule awareness as process, never a halfin-held certification.
- Bettor identity, jurisdiction, and responsible-gambling checks stay in your platform.
- Invoices, payouts, and webhooks attach to your bettor IDs for your own reconciliation.
# Fund a bettor's balance: fiat-anchored invoice, rate locked at activation.
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": "40.00",
"fiat_currency": "USD",
"deferred": true,
"idempotency_key": "deposit-bettor-5523-00187"
}'
# The response carries a hosted checkout URL on checkout.thehalfin.com;
# see docs.thehalfin.com for the full schema. Redirect the bettor there,
# then verify the signed invoice.paid webhook on your server before
# crediting the betting balance. Pay a winner with the reverse flow:
# POST /api/v1/payouts, then act on the payout.completed webhook.