Как устроен процесс интеграции игры в казино
Интеграция игры — это не «подключили iframe». Это цепочка согласований, тестов, правовых и технических шагов между студией (провайдером), платформой/агрегатором и оператором. Ниже — практическая схема «от договора до первых реальных ставок».
1) Карта участников и зон ответственности
Студия (провайдер/RGS): игра и математика, RNG, API, логи, сертификаты, market builds, поддержка.
Агрегатор/платформа: единый API для операторов, маршрутизация, биллинг/отчётность, промо, комплаенс-хаб.
Оператор (казино): кошелёк/платежи, KYC/RG, витрина, маркетинг, клиентская поддержка.
Лаборатория/регулятор: проверка RNG/математики/логов, реестры одобренных билдов.
2) Этап 0. Прединтеграция (юридика и данные)
Что делаем:1. Договор(ы): rev-share / per-spin / гибрид, права на IP, перечень рынков.
2. Пакет комплаенса: сертификаты, RTP-профили, политика RG, ISO/ИБ.
3. Каталог и метаданные: RTP, волатильность, локали, возрастные пиктограммы, теги, иконки/видео.
4. План релизов: приоритетные рынки, даты, промо-пакет (фриспины/турнир).
3) Этап 1. Техподготовка и API
Основы: REST/HTTPS (иногда gRPC), UTC-тайм, ISO-валюты, JWT/HMAC, IP allowlist, mTLS.
Ключевые модели:- Сессия: `session_id, player_id, game_id, build_hash, country, currency, rg_flags`.
- Кошелёк: debit/credit (на лету) или transfer (баланс сессии). Для слотов чаще debit/credit.
- Идемпотентность: `spin_id/round_id` как ключи для повторов; ответ на повтор — тот же результат.
- События: `spin_finished, bonus_trigger, jackpot_contribution/win, rg_event, error`.
- Client → Platform: StartRound → Platform → RGS: Spin(stake) → RGS → Platform: Outcome(win) → Platform → Wallet: Debit/ Credit → Platform → Client: Result → Platform → EventBus: spin_finished.
4) Этап 2. Маркет-версии и сертификация
Market builds: язык, предупреждения, лимиты, допустимые RTP-версии.
Валидация: платформа проверяет `build_hash ↔ сертификат ↔ страна`.
Справки: правила, RTP, возрастные иконки, ссылки RG — в каждой локали.
Деморежим и ограничения: где разрешено — отдельные билды/флаги.
5) Этап 3. QA и тест-контуры
Sandbox (детерминированный RNG):- функционал, кошелёк, RG-сценарии, ошибки/ретраи, идемпотентность;
- автотесты payout-границ, бонусных состояний, каскадов.
- Локали/LQA, витрина, баннеры, возрастные метки, промо-модуль.
- Нагрузочные тесты: p95/p99 для `spin`, устойчивость к сетевым сбоям.
- Отказы кошелька и RGS: ретраи, идемпотентность, фолбэки UI.
- чек-листы витрины, категории/поиск, фильтры RTP/волатильности, быстрые ставки, история игр.
6) Этап 4. Интеграция промо и джекпотов
Фриспины: выдача пакетами, учёт `spin_type=free`, тариф в биллинге (часто сниженный или 0).
Турниры/миссии: метрики (мультипликатор/сумма/серии), анти-бот защита, live-таблицы.
Джекпоты: взносы и выплаты отдельными транзакциями; отчётность и форензика выигрыша.
7) Этап 5. Запуск (go-live)
Check-list дня X:- Домен/реестр IP и сертификаты mTLS.
- `build_hash` в белом списке по странам, RTP-профиль выбран.
- Баннеры/плитки на витрине, демо/региональная доступность.
- Мониторинг включён: latency/error, RTP-дрифт, частоты бонусов, аптайм.
- Каналы инцидентов (Pager/Slack/Email), 24×7 контакты.
- Пилотная промо-акция (фриспины/мини-турнир).
8) Этап 6. Отчётность и биллинг
Событийный слой: `stake, win, currency, spin_type, game_id, build_hash, operator_id, ts_utc`.
Сводные отчёты: оборот, GGR, NetWin, eligible spins, джекпот-взносы, бонус-кост, роялти/комиссии.
Модели выплат: rev-share (от NetWin/GGR), per-spin/turnover-fee, гибрид.
True-up: квартальные сверки исключений (free/test), FX и late-posting.
9) Пост-релизный мониторинг и инциденты
RTP-guardrails: онлайн-окна (напр., 10–50 млн спинов) и алерты при выходе за доверительный интервал.
Бонус-частоты/стрики: детект аномалий (регрессия/ошибки конфигов).
SLA: p95 для spin ≤200–300 мс по регионам, доступность ≥99,9%.
Хотфиксы: без изменения математики — без пересертификации; математика затронута — план пересерта.
Аудит-лог и реплей: расследование спорных спинов за минуты.
10) Частые проблемы и как их предотвратить
1. Дубли транзакций. — Идемпотентные ключи для `debit/credit` и хранение статуса.
2. Неверный market build. — Автопроверка `build_hash` по стране и RTP в runtime.
3. Локализационные ошибки. — ICU-плюрали, числовые формы, возрастные пиктограммы, глоссарий.
4. Распухание latency. — Кэш метаданных, близкие регионы RGS, gRPC/Event Bus для потоков.
5. Несовпадение отчётов. — Единая схема событий, дедупликация, UTC и квартальный true-up.
6. RG-несоответствия. — Немедленный `403 RG_BLOCKED`, журнал RG-событий, витринные предупреждения.
7. Смешение версий. — Реестр билдов/хэшей, запрет «самосборов», канареечные выкладки.
11) Роли и коммуникации
Техлид интеграции (с обеих сторон): владелец критического пути и SLA.
Комплаенс-офицер: сертификаты, market builds, документация RG.
QA-лид: сценарии Sandbox/Staging/UAT, отчёты по блокерам.
BD/Маркетинг: витрина, баннеры, промо-сетап, календарь.
SRE/DevOps: мониторинг, алерты, аварийные регламенты.
12) Чек-листы
Студия → Оператор/Агрегатор
- OpenAPI/спеки и примеры пэйлоадов.
- Идемпотентность `spin/debit/credit/jackpot`.
- RNG-реплей по `seed/nonce`, WORM-хранилище логов.
- Сертификаты, RTP-линейка, market builds, справки/локали.
- Нагрузочные тесты и хаос-сценарии сети.
Оператор → Студия
- Wallet API с идемпотентностью и ретраями.
- Geo-маппинг, age-labels, RG-политики.
- Витрина/категории/поиск подключены к метаданным.
- Промо-модуль: фриспины/турниры/миссии.
- Дэшборды SLA и отчётность/true-up.
13) 30-60-90: дорожная карта интеграции
0–30 дней (подготовка)
Контракты и markets, каталог и метаданные, пакет сертификации.
Согласование API (кошерёк, спин, события), подъем Sandbox с фикс-seed RNG.
Реестр `build_hash` и первичная матрица market builds.
31–60 дней (интеграция и тесты)
Подключение кошелька и спинов, Event Bus и наблюдаемость.
Нагрузочные/хаос-тесты, LQA локалей, настройка витрины и промо.
UAT у оператора, финальные фиксы.
61–90 дней (запуск и сопровождение)
Go-live на пилотных рынках, фриспин-или турнирное промо.
Биллинг/отчётность, квартальный true-up.
Пост-релизные алерты RTP/частот, план хотфиксов и пересертификаций.
14) Короткий FAQ
Можно ли менять RTP после релиза? Только на заранее сертифицированные профили и с корректным market build.
Нужен ли iframe/веб-вью? Чаще да; натив — по спец-партнёрам. Важно: защита клиента (anti-tamper, подписи ассетов).
Кто платит за джекпоты/промо? По договору: взносы обычно до NetWin, призовые турниров — отдельные сметы.
Как быстро расследовать спорный спин? Реплей по `spin_id/seed` + аудит-лог + сверка `build_hash`.
Процесс интеграции — это управляемая конвейерная работа: контракты → API/кошелёк → market builds/сертификация → QA/UAT → промо/запуск → биллинг/мониторинг. Когда у сторон есть идемпотентность, прозрачные события, строгая матрица билдов и дисциплина RG, игра выходит быстро, безопасно и предсказуемо — а пост-релизные инциденты решаются минутами, а не днями.