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

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

Запуск 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.

Крипто-специфіка: блокчейн баланс

Якщо платформа працює з криптовалютними балансами (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) — інший підхід, прискорює додавання нових ігор ціною втрати контролю над балансом.