What a casino payment gateway actually has to do
Strip a casino cashier down to its money plumbing and three jobs remain. Take the deposit: the player picks an amount, you collect it, and you credit their in-game balance the moment the money is real. Hold and convert: the balance sits in your treasury, possibly in a different asset than you want to settle in. Pay the cashout: the player requests a withdrawal, your back office approves it, and the money lands in their wallet. Everything else — game outcomes, bonuses, wagering requirements, responsible-gaming limits — sits on top of those three movements and is yours to run.
The reason this is hard on card rails is that none of the three jobs is clean. Deposits get declined by issuers who treat gaming MCCs as high-risk, so a player who wanted to fund a bet stares at a generic decline and leaves. Cashouts route back through the same card networks as refunds, which are slow and themselves declinable. And the deposit you already credited and paid winnings against can be reversed by a chargeback long after the result settled. A crypto gateway removes those three specific failure modes, one per job.
halfin is the layer that turns those three jobs into named API calls. A deposit is an invoice plus a hosted checkout page. A held balance is your treasury, with balance conversion when you need to move between assets. A cashout is a payout. Each one emits an HMAC-signed webhook that your server verifies before it moves a player's balance. You don't get a casino back office from halfin; you get the cashier rails the back office sits on.
Deposits: hosted checkout the player can actually complete
A casino deposit starts the same way every time: the player chooses how much to add, in a fiat figure they understand. You create a fiat-anchored invoice for that figure, so the value credited matches the number they typed regardless of which asset they pay in. The rate is locked at activation, so a player who takes a minute to open their wallet still gets the amount they agreed to. Then you redirect to hosted checkout on checkout.thehalfin.com, where they pay from their own wallet on a network you accept.
The asset and network are the player's, not yours to dictate. A player holding USDT on Tron and a player holding USDC on Solana both land on the same invoice and both credit to the same fiat figure. Stablecoins are the workhorse for casino deposits because the credited value doesn't drift between the deposit decision and the on-chain confirmation. For a player who deposits often, hand out a static deposit address once and credit every payment that lands on it — no per-deposit checkout step at all.
The credit itself is on-chain truth, not an optimistic spinner. 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 instant it does, your server gets a signed invoice.paid webhook. A player who sends slightly too little produces an invoice.underpaid event you can act on, instead of a silent mismatch your support desk finds at month-end reconciliation.
- Fiat-anchored invoice — credit matches the figure the player chose, in any supported asset.
- Rate locked at activation — a slow fund doesn't change the credited amount.
- Hosted checkout on checkout.thehalfin.com, or a static deposit address for regular players.
- Reorg-aware crediting at the per-chain threshold, then a signed invoice.paid webhook.
- invoice.underpaid / invoice.overpaid recorded explicitly against the quote — no silent mismatch.
Withdrawals: a payout, not a bank transfer you wait on
A cashout is where a casino's reputation is decided, and on crypto rails it is mechanically simpler than a deposit. Your platform owns the decision — KYC status, wagering requirements met, fraud checks cleared — and that decision stays yours. Once your back office approves the withdrawal, you create a single payout to the player's wallet. Because no card issuer can decline an approved payout the way one declines a refund, the cashout goes out as fast as the chain confirms it.
Payouts don't fire the instant you call the API. Each one enters a pending-approval state and is released from the dashboard, so the call your integration makes is a proposal that a treasurer signs off before any money leaves the balance — keeping the programmatic path separate from the human control point that a regulated operator's finance team wants. The payout.completed webhook is the event that moves the player's balance and your treasury record — not the API response, not the dashboard view.
When you run scheduled or bulk withdrawal runs — VIP rebates, weekly settlements, an affiliate revenue-share batch — you fan out over the same single-payout API, with a deterministic idempotency_key per line. A run that dies halfway and gets re-submitted pays each recipient exactly once, because a repeated key returns the payout halfin already created instead of making a second one — the property a hand-rolled withdrawal loop never has and a casino payout run needs.
No chargebacks, and the honest version of that
The single biggest reason casinos move to crypto rails is irreversibility. A confirmed on-chain deposit is final: the player cannot call their bank weeks later and reverse a bet they lost. That closes the friendly-fraud vector card processors leave open, and deposits that credit stay credited — you are not carrying a rolling reserve against reversals that may or may not arrive.
The honest framing matters because irreversibility cuts both ways. Since a confirmed deposit can't be clawed back by the sender, a genuine return is a deliberate action you take, not a button the player presses. 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. You keep control of when money goes back.
The day-to-day effect is a quieter ledger. Reconciliation becomes a matter of matching signed events — invoice.paid in, payout.completed out — against player and treasury movements, instead of chasing reversals that surface long after the game has been played.
The casino cashier, mapped to halfin primitives
Every cashier job lines up with a named halfin primitive, so an integration is a checklist rather than a design exercise — what the player or operator does, which primitive carries it, and the signed event your server keys off of.
| Cashier job | halfin primitive | Authoritative event |
|---|---|---|
| Player deposit (one-off) | Fiat-anchored invoice + hosted checkout | invoice.paid |
| Player deposit (recurring / VIP) | Static deposit address | invoice.paid |
| Short deposit | Invoice underpayment handling | invoice.underpaid |
| Hold and rebalance treasury | Balance conversion | — |
| Single cashout | Single payout (operator-approved) | payout.completed |
| Bulk withdrawal / rebate run | Idempotent payout fan-out | payout.completed |
| Return a deposit | Refund | — |
Create a casino deposit invoice
The deposit integration is small enough to show in full. Create a fiat-anchored invoice for the amount the player chose, redirect them to the hosted checkout URL in the response, and wait for the signed invoice.paid webhook before you credit the in-game balance. The request below sends the fiat figure and its currency; the asset and network are chosen by the player on the checkout page. The full request and response schema lives at docs.thehalfin.com.
Treat the webhook as authoritative and the redirect as cosmetic. A player can pay and close the tab before the success redirect ever fires, but the signed invoice.paid webhook still arrives — verify its HMAC signature, then credit the player. The same pattern runs in reverse for cashouts: your back office approves the withdrawal, you create a payout, and payout.completed 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,
"idempotency_key": "deposit-player-8821-00041"
}'
# The response includes a hosted checkout URL on checkout.thehalfin.com;
# see docs.thehalfin.com for the full invoice schema. Redirect the player
# there, then verify the signed invoice.paid webhook on your server
# before crediting the in-game balance.Infrastructure, not a gaming license
Running an online casino 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 any obligation you carry in the markets you serve. Whether your casino may operate in a given jurisdiction is your question to answer with your own counsel and your own regulator — not a status halfin confers by processing your payments.
What halfin does provide is process. Operator onboarding runs through KYB so halfin knows the business it processes for. Processing on the rails is AML-aware, and travel-rule expectations are something to design around — none of which is a certification halfin holds on your behalf, or a claim that your casino is approved to run.
The division of responsibility keeps both the compliance story and the integration clean. Your platform owns player identity, age and jurisdiction checks, responsible-gaming controls, 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 against. Player KYC stays your system of record; halfin's invoices and payouts attach to your player IDs for your own controls.
- halfin issues no gambling license and gives no legal or licensing advice.
- KYB onboarding for the operator; 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.
- Invoices, payouts, and webhooks attach to your player IDs for your controls.