Crypto payments for iGaming: casinos, sportsbooks, and poker rooms

iGaming operators lose players at two moments: a deposit that takes too long to clear, and a withdrawal that takes too long to land. Cards make both worse — declines on gaming MCCs are common, and a chargeback weeks later can claw back a settled bet. halfin is the payment infrastructure that sits underneath a casino, sportsbook, or poker room: crypto deposits that confirm on-chain, player withdrawals you push as payouts, and affiliate settlement on the same rails. It is a payment layer, not a gambling license — your operation keeps its own onboarding, game logic, and regulatory standing.

The problem: player money has to move at the speed of play

A player who decides to deposit has already decided to play. If the deposit is declined or held, that intent leaks away — to a competitor, or to nothing. Card networks treat gambling merchant categories as high-risk, so approval rates sag, issuers block, and the player who wanted to fund a $40 bet ends up staring at a generic decline they cannot fix. The operator never sees the failure; they just see a player who did not come back.

Withdrawals are the other half of the same problem, and they are where reputation is made. A player who wins expects their money quickly. When a payout sits in a manual queue for days, the player posts about it, the support desk fills with tickets, and the affiliate who sent that player stops sending more. Slow withdrawals are not a finance inconvenience — they are a retention and acquisition problem wearing a finance costume.

And then there is the chargeback. A card deposit can be reversed weeks after the bet has been placed, the game has been played, and the result has settled. The operator has already paid out winnings on a deposit that just evaporated. For a casino or sportsbook running thousands of small transactions, chargeback fraud and friendly-fraud reversals are a structural leak that card rails simply do not close.

Crypto removes those specific failure modes. An on-chain deposit either confirms or it does not — there is no issuer in the middle to decline it, and once it is credited under the chain's confirmation rules it cannot be reversed by the sender. Withdrawals become a payout you push, not a bank transfer you wait on. The job that remains is wiring those rails into the deposit, withdrawal, conversion, and reconciliation flow your platform already runs — which is exactly what halfin provides.

How halfin maps onto the iGaming money flow

halfin does not become your casino back office. It gives you payment primitives that slot into the flow you already run: collect a deposit, watch the chain, credit the player, hold a balance, pay a withdrawal, settle affiliates, and reconcile all of it from one API. Each step maps onto a named halfin primitive rather than a black box.

Deposits start as an invoice or a static deposit address. Hosted checkout is the fastest path for player-facing deposits — you create a fiat-anchored invoice for the amount the player chose, redirect them to checkout.thehalfin.com, and they pay from their own wallet on a network you accept. For a deposit page that lives entirely inside your own product, self-hosted checkout renders against the same API on your domain. For high-volume players you can hand out a static deposit address once and credit every payment that lands on it, with no per-deposit checkout step.

Crediting is on-chain truth, not a hopeful UI. halfin applies each chain's confirmation threshold and credits reorg-aware, so a deposit shown as confirmed has actually settled under that chain's rules. The moment it does, your server receives an HMAC-signed webhook — verify the signature, then credit the player balance. The webhook is the source of truth for your ledger; the checkout redirect is only for the player's eyes.

Withdrawals are payouts. A single approved cashout is a single payout to the player's wallet, executed with operator review and an audit trail. Batched payouts — affiliate runs, rebates, weekly settlements — go through idempotent batch payouts so a retried request never double-pays. Balance conversion handles the treasury side: a sportsbook that takes USDT on Tron but settles affiliates in USDC can convert balances automatically or manually instead of running an external desk.

• Deposit → hosted checkout, self-hosted checkout, or a static deposit address.
• Confirm → reorg-aware crediting at the per-chain threshold, signed webhook to your server.
• Credit → verify the webhook signature, then move the player balance.
• Withdraw → single payout for a cashout, batch payout for affiliate and rebate runs.
• Settle → balance conversion for treasury rebalancing across assets and chains.
• Reconcile → dashboard records plus signed events your finance team can close on.

The deposit and withdrawal flows in detail

Deposits and withdrawals are the two flows a player feels directly, so they deserve to be concrete. On the deposit side, the player picks an amount, you create an invoice anchored to a fiat figure so the credited value matches what the player expects, and the rate is locked at activation rather than drifting while they fund. The player pays in the asset and network they already hold — a USDT-on-Tron player and a USDC-on-Solana player both land on the same invoice. Underpayment and overpayment are recorded explicitly against what was quoted, so a player who sends slightly too little does not vanish into a silent mismatch your support desk discovers at reconciliation.

On the withdrawal side, your platform owns the decision — KYC status, bonus wagering, fraud checks — and halfin owns the execution. Once your back office approves a cashout, you create a payout to the player's wallet. Because payouts run on the same chains you accept deposits on, a player can withdraw to the wallet they deposited from. High approval rates here are structural, not a feature you toggle: there is no issuer to decline a payout the way a card processor declines a refund, so an approved withdrawal goes out as fast as the chain confirms it.

The two flows share one discipline: signed events drive your ledger. A deposit credits a player only after you verify the webhook signature; a payout updates the player's balance and your treasury only on the payout.completed webhook. The dashboard gives operators a human view of every invoice and payout, but the webhook is what your automated player-balance logic trusts.

Supported deposit rails

Players show up holding different assets on different chains, and the rail that fails is the one you do not support. halfin runs real on-chain gates for each network below — there is no placeholder rail that quietly does nothing — and stablecoins are the workhorse for gaming deposits because the credited value does not move between the bet decision and the confirmation. USDT and USDC are the assets most players reach for; native coins cover the rest.

The iGaming flows operators ask about first

Most operators arrive with a short list of payment jobs they need to cover before launch. Each one maps onto the primitives above; here is how the common iGaming use cases translate into a halfin setup, so you can plan an integration without guessing.

• Casino payment gateway — a deposit page (hosted or self-hosted checkout) that takes the player's chosen asset, credits the balance on a signed confirmation, and never touches a card field.
• Sports-betting payments — fiat-anchored invoices so the deposit matches the stake the bettor intended, with rate lock at activation so a slow fund does not change the credited amount.
• Poker-room payouts — single payouts for individual cashouts to a player's wallet, with operator review and an audit trail for every approved withdrawal.
• Affiliate-network payouts — idempotent batch payouts for weekly affiliate, rebate, and revenue-share runs, so a retried batch never pays a partner twice.
• Crypto deposits for casinos — static deposit addresses for recurring or high-volume players, crediting every payment that lands on the address without a per-deposit checkout step.
• Instant withdrawals for players — payouts that go out as fast as the chain confirms, with no issuer in the loop to decline an approved cashout.
• Compliance for iGaming — KYB onboarding for the operator and AML-aware processing on the rails, with payment records attached to player IDs for your own controls.

No chargebacks, and what that actually changes

The single biggest difference between card rails and crypto rails for a gaming operator is irreversibility. A confirmed on-chain deposit is final; the player cannot dial their bank weeks later and reverse a bet they lost. For a sportsbook or casino, that closes a fraud vector that card processors leave wide open and price into their gaming-MCC fees.

Irreversibility cuts both ways, and the honest framing matters: because a confirmed deposit cannot be clawed back by the sender, a genuine mistake is handled deliberately, not by a chargeback button. halfin's refunds primitive exists for exactly this — 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 the fact. You keep control of when money goes back; the player cannot force it.

The practical effect on operations is fewer surprises in the ledger. Deposits that credit stay credited. Withdrawals that go out are recorded as payouts, not as refunds against a card. Reconciliation becomes a matter of matching signed events to player and treasury movements, instead of carrying a rolling reserve against reversals that may or may not arrive.

Compliance: KYB and AML are process, not a license

iGaming is a regulated activity, and the regulation belongs to the operator. halfin is payment infrastructure — it does not issue gambling licenses, does not provide legal or licensing advice, and does not replace the operator's obligations in the markets it serves. Whether a casino, sportsbook, or poker room may operate in a given jurisdiction is the operator's question to answer with its own counsel and its own regulator.

What halfin does provide is process, not a certificate. Operator onboarding runs through KYB so halfin knows the business it is processing for. Processing on the rails is AML-aware, and travel-rule expectations are something to understand and design for as a process — none of this is a status halfin holds on your behalf, and none of it should be read as a claim that your operation is approved to run.

The clean division of responsibility is the same one that keeps the integration sane. Your platform owns player identity, age and jurisdiction checks, responsible-gaming controls, and the decision to accept a deposit or release a withdrawal. halfin receives the approved payment instruction, processes the rail, keeps the payment record, and returns signed status your compliance and finance teams can reconcile. Player KYC stays your system of record; payment records attach to your player IDs.

• Operator onboarding via KYB; halfin knows who it processes for.
• AML-aware processing and travel-rule awareness as process, never a halfin-held certification.
• Player identity, jurisdiction, and responsible-gaming checks stay in your platform.
• Payment records (invoices, payouts, webhooks) attach to your player IDs for your controls.

Create a player deposit invoice

The deposit integration is small enough to show in full. Create a fiat-anchored invoice for the amount the player selected and the networks you accept, then redirect the player to the hosted checkout URL in the response and wait for the signed invoice webhook before you credit the balance. The full request and response schema lives at docs.thehalfin.com — the call below shows the headers and the amount and currency you send.

Treat the webhook as authoritative and the redirect as cosmetic: a player can pay and close the tab before the success redirect fires, but the signed invoice.paid webhook still arrives. Verify its signature, then credit the player. The same pattern in reverse drives withdrawals — your back office approves the cashout, you create a payout, and the payout.completed webhook is what moves the player balance and your treasury.

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": "50.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Player deposit",
    "idempotency_key": "deposit-player-8821-00041"
  }'

# The response includes a hosted checkout URL on checkout.thehalfin.com;
# see docs.thehalfin.com for its full schema. Redirect the player there,
# then verify the signed invoice.paid webhook on your server before
# crediting the player balance.