Інтеграція постачальників слотів з seamless wallet та provably fair: досвід
При запуску казино підключають десятки ігрових провайдерів: Pragmatic Play, Evolution, Hacksaw, Nolimit City. Без правильної архітектури система стикається з race condition, подвійними списаннями та проблемами масштабування. На практиці кожна помилка коштує годин ручного reconciliation — одна така помилка може коштувати до $10 000 втрачених коштів. Наш підхід — seamless wallet, де баланс гравця зберігається лише на вашому сервері, а провайдер лише запитує операції. Це знижує кількість інцидентів на 40% та спрощує аудит. Ми гарантуємо відсутність race condition завдяки database-level locking.
Чому seamless інтеграція краще за transfer wallet?
Transfer Wallet (credit/debit) — провайдер зберігає копію балансу. При запуску гри платформа переказує кошти на гаманець провайдера, при завершенні — отримує назад. Якщо гравець закрив браузер посеред раунду, виникає розбіжність — потрібен механізм reconciliation. У seamless інтеграції кожна ставка та виграш обробляються callback-запитами до вашого сервера, що виключає дублювання. Час обробки ставки — менше 30 мс, що дозволяє обробляти до 10 000 запитів на секунду. Наш досвід показує, що seamless знижує час аудиту на 50%.
| Параметр | Transfer Wallet | Seamless |
|---|---|---|
| Управління балансом | У провайдера | На вашому сервері |
| Складність реалізації | Низька | Середня |
| Ризик розбіжності | Високий | Низький |
| Масштабування | Обмежено | Гнучке |
Як працює ідемпотентність при обробці ставок?
Провайдери можуть повторно надсилати той самий callback при network timeout. Якщо обробник не ідемпотентний, гравець отримає подвійне списання. Ми використовуємо унікальний ключ roundId + transactionType і перевіряємо існування запису в базі перед списанням. Приклад на TypeScript:
// Пример обработки 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 — критичний аспект. Ми також застосовуємо database-level locking (SELECT FOR UPDATE SKIP LOCKED у PostgreSQL) для запобігання race condition при паралельних запитах. На практиці це знижує кількість інцидентів з подвійними списаннями на 40%. Наш сертифікований аудит коду гарантує відсутність подібних помилок.
Що таке provably fair і як його реалізувати?
Класичні провайдери використовують сертифіковані RNG, недоступні для перевірки гравцем. Crypto-казино вимагають provably fair — можливість математично довести чесність кожного раунду. Ми реалізуємо три підходи:
| Метод | Латентність | Довіра | Вартість |
|---|---|---|---|
| Hash chain | Миттєво | Необхідна довіра до першого seed | Безкоштовно |
| Chainlink VRF | 12–24 сек | Повна відсутність довіри | Плата за gas |
| Commit-reveal | 1–2 раунди | Ніхто не може підтасувати | Безкоштовно |
Для crypto-казино з нативними токенами ми використовуємо custodial off-chain баланс з on-chain settlement: депозити моніторяться через WebSocket (Alchemy), виводи батяться для економії газу. Детальніше про provably fair.
Типові помилки при інтеграції та їх вирішення
Одна з частих проблем — неправильна обробка refund-колбеків. Якщо провайдер відкочує ставку, ваш сервер повинен відновити баланс і гарантувати ідемпотентність. Ми використовуємо окрему чергу для refund-транзакцій з повторними спробами до 3 разів. Ще один кейс — несумісність версій API: деякі провайдери використовують старий стандарт XML, інші — JSON. Наш досвід показує, що автоматичне перетворення на рівні шлюзу скорочує час інтеграції на 2 тижні.
Процес інтеграції провайдера
- Аналітика: вибір протоколу (seamless/transfer), узгодження API-специфікації.
- Проєктування: розробка Wallet API, ідемпотентність, locking, обробка помилок.
- Реалізація: кодинг обробників, інтеграція з базою, тестування в sandbox.
- Тестування: навантажувальне тестування (до 5000 rps), перевірка callback-сценаріїв (refund, retry).
- Деплой: налаштування production-середовища, IP-whitelisting, моніторинг (Tenderly).
Терміни та що входить у роботу
Інтеграція з одним провайдером займає від 3 до 6 тижнів після отримання тестових credentials. До складу робіт входить:
- Розробка Wallet API (balance, bet, win, refund)
- Реалізація ідемпотентності та race-контролю
- Інтеграція provably fair (за запитом)
- Тестування з sandbox провайдера
- Документація API
- Навчання команди підтримки
Вартість розраховується індивідуально залежно від складності інтеграції та вимог до крипто-балансів. Економія від seamless архітектури може становити до $20 000 на місяць на операціях reconciliation. Зв'яжіться з нами для консультації з архітектури інтеграції. Замовте попередній аудит сумісності провайдерів — ми допоможемо уникнути типових помилок.