Интеграция казино с провайдером слотов

Интеграция казино с провайдером слотов

Запуск online-казино с нуля с разработкой собственных игровых движков — экономически нецелесообразно. На рынке существуют десятки game content provider'ов (Pragmatic Play, Evolution, BGaming, Hacksaw, Nolimit City), которые предоставляют готовые слоты и live-казино через стандартизированные интеграционные протоколы. Задача интегратора — подключить эти провайдеры к вашей платформе: аутентификация игроков, управление балансом, обработка ставок, отображение игрового контента.

Архитектура интеграции: Seamless vs Transfer

Два принципиально разных подхода к интеграции провайдера:

Transfer Wallet (Credit/Debit) — у провайдера своя копия баланса игрока. При запуске игры платформа "переводит" средства на кошелёк провайдера, при завершении игры — получает обратно. Проще в реализации, но создаёт проблему двойной транзакции: что если игрок закрыл браузер в середине игры? Нужен механизм reconciliation.

Seamless Integration — провайдер не хранит баланс. При каждой ставке/выигрыше провайдер делает callback-запрос на ваш сервер. Ваш сервер является single source of truth для баланса. Это стандарт для серьёзных платформ.

При Seamless интеграции провайдер делает три типа callbacks:

Реализация Wallet API

Провайдеры требуют от вашего сервера API эндпоинты для обработки callbacks. Большинство используют XML или JSON поверх HTTPS с IP-whitelisting и подписью запросов (HMAC или секретный токен в заголовке).

// Пример обработки bet callback (Pragmatic Play стиль)
app.post("/casino/wallet/bet", async (req, res) => {
  const { userId, gameId, roundId, amount, currency, hash } = req.body;

  // Верификация подписи
  if (!verifyHash(req.body, process.env.PROVIDER_SECRET_KEY)) {
    return res.json({ error: 1, description: "Invalid signature" });
  }

  // Idempotency: проверяем что roundId ещё не обрабатывался
  const existing = await db.rounds.findByRoundId(roundId);
  if (existing) {
    return res.json({
      error: 0,
      balance: existing.balanceAfter,
      transactionId: existing.transactionId,
    });
  }

  // Списание баланса в транзакции
  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 — критический момент: провайдеры могут повторно отправить один и тот же callback при network timeout. Если ваш обработчик не идемпотентен — игрок получит двойное списание. Каждый roundId + transactionType должен обрабатываться ровно один раз.

Database-level locking: при параллельных запросах (несколько слотов одновременно) без SELECT FOR UPDATE или оптимистичных locks можно получить race condition на балансе. PostgreSQL FOR UPDATE SKIP LOCKED или Redis distributed lock для balance operations.

Crypto-специфика: блокчейн баланс

Если платформа работает с криптовалютными балансами (USDT, ETH, нативный токен), архитектура усложняется: нельзя напрямую читать on-chain баланс при каждом callback провайдера — это слишком медленно.

Решение — custodial off-chain balance с on-chain settle:

On-chain wallet → Deposit detection → Platform internal balance
                                          ↓
                               Game provider callbacks (fast)
                                          ↓
                            Withdrawal request → On-chain transfer

Deposit flow: мониторинг входящих транзакций на кошелёк пользователя через WebSocket (Alchemy eth_subscribe("logs") или Moralis webhook). После N подтверждений — кредит на internal balance.

Withdrawal flow: запрос на вывод попадает в очередь, обрабатывается batch-операцией (экономия gas), on-chain транзакция создаётся с разумным gas price.

Provably Fair и RNG для crypto-казино

Классические провайдеры используют сертифицированные RNG (iTech Labs, GLI), недоступные для аудита пользователем. Crypto-казино часто требуют "provably fair" механику — возможность математически доказать честность каждого раунда.

Варианты реализации:

Hash chain scheme: сервер генерирует серию хэшей H_n = hash(H_{n-1}). Открывает H_0 (seed) до игры, раскрывает H_1 после. Пользователь может верифицировать что hash(H_1) == H_0.

Chainlink VRF: on-chain верифицируемая случайность. Запрос через requestRandomWords(), callback с fulfillRandomWords(). VRF proof публично верифицируем — никто, включая оператора, не может предсказать результат. Латентность: 1–2 блока (~12–24 сек на Ethereum), что приемлемо для слотов, но не для roulette.

Commit-reveal: клиент генерирует случайное число, хэширует и отправляет серверу до старта раунда (commit). Сервер генерирует своё число. После раунда оба раскрывают числа (reveal), результат = XOR. Никто из сторон не может манипулировать результатом зная commited значение другой стороны.

Лицензирование и compliance

Интеграция с licensed провайдером (Pragmatic Play, Evolution) требует собственной gaming лицензии. Без неё провайдер не предоставит production credentials. Популярные юрисдикции: Malta MGA, Gibraltar, Curaçao eGaming. Curaçao — самый доступный и быстрый путь (от $15k, 6–8 недель), MGA — наиболее prestige, но $25k+ и 4–6 месяцев.

KYC/AML интеграция (Jumio, Onfido, Sum&Substance) обязательна для большинства лицензий. Это влияет на архитектуру: игровой кабинет, лимиты ставок, отчётность по подозрительным транзакциям.

Типичный срок интеграции с одним провайдером после получения test credentials: 3–6 недель. Мультипровайдерная платформа с агрегатором (Softswiss, EveryMatrix) — другой подход, ускоряет добавление новых игр ценой потери контроля над балансом.