Як влаштований процес інтеграції гри в казино

Інтеграція гри - це не «підключили 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-кордонів, бонусних станів, каскадів.

Staging (копія прод-інфри):

Локалі/LQA, вітрина, банери, вікові мітки, промо-модуль.
Навантажувальні тести: p95/p99 для'spin', стійкість до мережевих збоїв.
Відмови гаманця і RGS: ретраї, ідемпотентність, фолбеки UI.

UAT у оператора:

чек-листи вітрини, категорії/пошук, фільтри 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, гра виходить швидко, безпечно і передбачувано - а пост-релізні інциденти вирішуються хвилинами, а не днями.