Casino Integration with Slots Provider
Launching online casino from scratch with developing own game engines is economically impractical. Market has dozens of game content providers (Pragmatic Play, Evolution, BGaming, Hacksaw, Nolimit City) that provide ready-made slots and live casino via standardized integration protocols. Integrator's task — connect these providers to your platform: player authentication, balance management, bet processing, game content display.
Integration Architecture: Seamless vs Transfer
Two fundamentally different approaches to provider integration:
Transfer Wallet (Credit/Debit) — provider has own copy of player balance. When launching game platform "transfers" funds to provider wallet, when finishing — receives back. Simpler implementation, but creates double transaction problem: what if player closed browser mid-game? Need reconciliation mechanism.
Seamless Integration — provider doesn't store balance. With each bet/win provider makes callback request to your server. Your server is single source of truth for balance. This is standard for serious platforms.
In Seamless integration provider makes three callback types:
| Callback | When | What It Does |
|---|---|---|
balance |
When launching game and on request | Provider asks current player balance |
bet (debit) |
When placing bet | Subtract bet sum from balance |
win (credit) |
When winning | Credit winnings to balance |
refund |
On technical error | Return bet (retry scenario) |
Wallet API Implementation
Providers require API endpoints from your server to handle callbacks. Most use XML or JSON over HTTPS with IP-whitelisting and request signing (HMAC or secret token in header).
// Example bet callback handling (Pragmatic Play style)
app.post("/casino/wallet/bet", async (req, res) => {
const { userId, gameId, roundId, amount, currency, hash } = req.body;
// Verify signature
if (!verifyHash(req.body, process.env.PROVIDER_SECRET_KEY)) {
return res.json({ error: 1, description: "Invalid signature" });
}
// Idempotency: check that roundId hasn't been processed yet
const existing = await db.rounds.findByRoundId(roundId);
if (existing) {
return res.json({
error: 0,
balance: existing.balanceAfter,
transactionId: existing.transactionId,
});
}
// Deduct balance in transaction
const result = await db.transaction(async (trx) => {
const player = await trx.players.lockForUpdate(userId);
if (player.balance < amount) {
throw new InsufficientFundsError();
}
await trx.players.updateBalance(userId, player.balance - amount);
return await trx.rounds.create({ roundId, userId, amount, type: "bet" });
});
res.json({
error: 0,
balance: result.balanceAfter,
transactionId: result.id,
});
});
Idempotency — critical: providers can resend same callback on network timeout. If handler not idempotent — player gets double debit. Each roundId + transactionType must be processed exactly once.
Database-level locking: with parallel requests (multiple slots simultaneously) without SELECT FOR UPDATE or optimistic locks you get race condition on balance. PostgreSQL FOR UPDATE SKIP LOCKED or Redis distributed lock for balance operations.
Crypto-Specific: Blockchain Balance
If platform works with cryptocurrency balances (USDT, ETH, native token), architecture becomes more complex: can't directly read on-chain balance on each provider callback — too slow.
Solution — custodial off-chain balance with on-chain settle:
On-chain wallet → Deposit detection → Platform internal balance
↓
Game provider callbacks (fast)
↓
Withdrawal request → On-chain transfer
Deposit flow: monitor incoming transactions to user wallet via WebSocket (Alchemy eth_subscribe("logs") or Moralis webhook). After N confirmations — credit internal balance.
Withdrawal flow: withdrawal request goes into queue, processed as batch (gas savings), on-chain transaction created with reasonable gas price.
Provably Fair and RNG for Crypto-Casino
Classic providers use certified RNG (iTech Labs, GLI), unavailable for user audit. Crypto-casino often require "provably fair" mechanic — ability to mathematically prove each round fairness.
Implementation variants:
Hash chain scheme: server generates hash series H_n = hash(H_{n-1}). Opens H_0 (seed) before game, reveals H_1 after. User can verify that hash(H_1) == H_0.
Chainlink VRF: on-chain verifiable randomness. Request via requestRandomWords(), callback with fulfillRandomWords(). VRF proof publicly verifiable — no one, including operator, can predict result. Latency: 1–2 blocks (~12–24 sec on Ethereum), acceptable for slots but not roulette.
Commit-reveal: client generates random number, hashes and sends to server before round start (commit). Server generates its number. After round both reveal numbers (reveal), result = XOR. Neither party can manipulate result knowing other's committed value.
Licensing and Compliance
Integration with licensed provider (Pragmatic Play, Evolution) requires own gaming license. Without it provider won't provide production credentials. Popular jurisdictions: Malta MGA, Gibraltar, Curaçao eGaming. Curaçao — most accessible and fastest path (from $15k, 6–8 weeks), MGA — most prestigious but $25k+ and 4–6 months.
KYC/AML integration (Jumio, Onfido, Sum&Substance) mandatory for most licenses. Affects architecture: game cabinet, bet limits, reporting for suspicious transactions.
Typical integration timeline with one provider after getting test credentials: 3–6 weeks. Multi-provider platform with aggregator (Softswiss, EveryMatrix) — different approach, accelerates adding new games at cost of losing balance control.