Перейти к содержанию

CEO Call Checklist: интеграция с агрегатором / оператором

Аудитория: founder / CTO / sales lead, готовящие CEO к звонку с интегратором. Это prep-документ, не для самого звонка. Содержит технические подробности, ADR'ы, ссылки на код.

Для самого звонка — простая шпаргалка для CEO (без жаргона, готовые фразы).

Незнакомый термин — в основном глоссарии. Технические термины (composite_token, generic_hmac, HMAC-SHA256, Centrifugo и т.п.) в продуктовый глоссарий не входят и поясняются прямо в чеклисте.

Как читать

Метки внутри текста:

  • [GAP] — известное ограничение в нашем продукте сегодня; нужно проговорить явно, не скрывая.
  • [POLICY?] — нет утверждённой позиции, требует решения CEO ДО звонка.
  • [ОРИЕНТИР] — индустриальный baseline из открытых источников; не наша обязательство, а рамка для разговора.

Без меток — факт из кода / ADR / документации, можно цитировать как точное.

Правило: если ответа нет под рукой — лучше «уточню и пришлю» чем выдумать на ходу. Ложь на звонке стоит дороже паузы.

Профили контрагентов

От профиля меняется и круг вопросов, и наша позиция. Перед звонком определи, с кем говорим:

Профиль Ключевое для них Что игнорировать
Прямой оператор Curaçao / крипто Wallet HMAC, PF, RTP-конфиг, онбординг GLI, MGA-RG, US/EU regs
Агрегатор (Hub88 / SOFTSWISS-style) Их wallet-протокол, sandbox, объём контента Прямые комм. условия
Sweepstakes-площадка US (Stake.us) Pool/GC/SC изоляция, AMOE, freebet flag EU-лицензии
Регулируемый MGA / UKGC оператор GLI, RG, audit log, A11y, ISO 27001 «Готовы за 4 недели»

Deal-breaker check (см. раздел 24): для регулируемых рынков мы сегодня не готовы. Если контрагент требует GLI in-hand — это длинная история, не «через квартал».

Что узнать ДО звонка (research, не задавать вслух)

  • Кто decision-maker и technical gatekeeper (LinkedIn).
  • Это оператор / агрегатор / white-label?
  • Сколько операторов в их сети и какие GEO они закрывают.
  • Их публичный каталог провайдеров — наши прямые конкуренты (Spribe, SmartSoft, BGaming, Pragmatic, Evolution).
  • Юрисдикция их лицензии — Curaçao / Anjouan / MGA / UKGC / Isle of Man / Costa Rica?
  • Их wallet-протокол, если публичен — Hub88-RSA, SOFTSWISS, Pragmatic, custom?
  • Срок их типового онбординга нового provider'а (Hub88 — от 3 дней; типичный агрегатор — 4–8 недель).
  • Публичные SLA-обязательства на их сайте.
  • Финансовое здоровье: parent company, новости о банкротстве / consolidations, AskGamblers black-list.
  • Какие крупные провайдеры у них недавно отвалились / добавились (sign of change).

1. Юр.модель и compliance ownership

1.1 Контрактная сторона

  1. На каком юр.лице заключаем контракт, кто подписант? [POLICY?]
  2. Юрисдикция, право, валюта, арбитраж? [POLICY?]
  3. Санкционные ограничения по контрагентам (OFAC, RU/BY)? [POLICY?]
  4. NDA подписан до раскрытия wallet_config и любых secret? [POLICY?]

1.2 Кто за что отвечает

  1. Geofencing (страна игрока) — оператор. Мы не получаем IP в Wallet API /authenticate, не валидируем юрисдикцию.
  2. Возрастной контроль (18+/21+) — оператор. Мы получаем уже валидированного игрока.
  3. KYC / AML / source of funds — оператор. Мы видим только транзакции через его wallet.
  4. Responsible gaming (self-exclusion, лимиты, reality checks, cooling-off) — оператор. Мы доверяем токену: если оператор выдал token, считаем игрока «допущенным». Виджет не блокирует excluded-игроков сам.
  5. PII у нас: player_id, display_name, история ставок, currency. Не храним: email, телефон, IP, документы, payment-данные, гео.
  6. GDPR-роль: мы processor для оператора. DPA подписываем по запросу.

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

  1. Есть ли у нас B2B-лицензия на supply of games? — [GAP] нет. Сегодня работаем в B2B grey-zone, compliance конечного игрока полностью на операторе.
  2. Готовы ли получить лицензию под рынок? [POLICY?] Возможные пути по индустрии: Anjouan (~€17k, ~4 нед.), Curaçao LOK (€4.6k initial + €47k годовых), Isle of Man / MGA — дороже и дольше. [ОРИЕНТИР]
  3. Какие рынки запрещены для нашего контента? [POLICY?]

2. Сертификация игр (RNG / GLI / iTech / BMM / eCOGRA)

  1. Что такое GLI-19 (Interactive Gaming Systems)? Стандарт для server-based онлайн-игр: RNG, фин-транзакции, PAM, безопасность, audit trail. Это релевант нам.
  2. Что такое GLI-33? Сертификат для спортсбука — нас не касается.
  3. Что такое GLI-11? Slot machines on a casino floor — оффлайн, не наш кейс.
  4. Кто кого выпускает: GLI (gold standard, нужен для US Nevada/NJ/MI/PA, MGA, UKGC), iTech Labs (дешевле, быстрее, стандарт для офшорных и semi-regulated юрисдикций), BMM Testlabs (восточные US-рынки, table games), eCOGRA (UK/EU). [ОРИЕНТИР]
  5. Сертифицированы ли наши игры сегодня? — [GAP] нет, ни одна. Сегодня мы компенсируем через Provably Fair (cryptographic proof of fairness). Это допустимо для крипто/sweepstakes/Curaçao, но не пройдёт для MGA/UKGC/US-операторов.
  6. Сколько занимает RNG-сертификация и сколько стоит? [ОРИЕНТИР] 6–12 недель + €15–40k за RNG-цикл; повторная сертификация при изменении математики; game-by-game (либо «семейство» с теми же payout tables — обсуждается с лабораторией).
  7. Кто оплачивает сертификацию — мы, оператор, 50/50? [POLICY?]
  8. Симуляция 1B раундов — обязательное требование RNG-цикла. У нас инструмент готов? — [GAP] инструмента симулятора-под-аудит как отдельной утилиты нет. Математика дискретная и описана в content/product/math/, реализация тривиальная (Crash — формула `crash_point = max(1.00, floor(RTP / random ×

100) / 100)`; Keno/Hilo — таблицы payout); требуется ~1-2 недели работы.

  1. Если контрагент требует сертификат до подключения — план B? [POLICY?] Варианты: Provably Fair как substitute для не-регулируемых рынков; отложить запуск до сертификации; пилот на грей-зоне с параллельной сертификацией.
  2. «RNG-сертифицирован» vs «Provably Fair» — разница:
    • RNG-сертификация: «доверьтесь нам, лаборатория проверила». Закрытый алгоритм, статистические тесты на N миллиардов раундов. Стандарт регулируемых рынков.
    • Provably Fair: «вот криптографическое доказательство, проверьте сами». Каждый раунд верифицируется игроком офлайн. Стандарт крипто-казино.
    • Они НЕ взаимоисключающие. Spribe Aviator делает оба: и GLI, и PF.
  3. Есть ли у нас ISO 27001 / SOC 2 / PCI DSS? — [GAP] нет. На грей-зоне обычно не требуется, но MGA/UKGC ожидают ISO 27001.

3. Provably Fair (наш USP)

  1. Что такое Provably Fair? Криптографическая схема commit-reveal. Сервер «запечатывает» результат раунда в SHA-256 хеш ДО ставки и публикует хеш игроку. После раунда раскрывает server_seed целиком, и игрок офлайн пересчитывает SHA256(server_seed) === published_hash. Совпало — результат не подменён.
  2. Чем наш Provably Fair отличается от стандартного (Stake, BC.Game, Spribe)? - Стандартная схема в индустрии: HMAC-SHA256(server_seed, client_seed || nonce) — включает client seed (игрок может его задать) и nonce-счётчик. - Наша схема: двойная соль соль₁ | result | соль₂, хеш — SHA-256(server_seed). Client seed и nonce не используются.
  3. Почему мы убрали client seed? Соли с двух сторон обеспечивают непредсказуемость без участия клиента — упрощает UX (игрок ничего не вводит) и аудит (меньше движущихся частей). По защите от перебора результата — эквивалентно.
  4. Покажите, как игрок верифицирует Crash-раунд:
    • Фаза betting: сервер публикует hash в Centrifugo-канал.
    • Игрок видит хеш в виджете до ставки.
    • Фаза crashed: сервер раскрывает server_seed = соль₁|crash_point|соль₂.
    • Виджет автоматически считает SHA-256 от строки и показывает результат проверки. Код — game-widget/src/lib/verifyHash.ts.
    • Игрок может скопировать server_seed и проверить в любом онлайн SHA-256 калькуляторе.
  5. Сколько энтропии в каждой соли? 8 байт криптографически стойкого CSPRNG = 16 hex-символов. Общая защита от перебора — 128 бит на одну обёртку соль₁|·|соль₂.
  6. Где хранятся seed-ы? Таблицы sessions (Keno/Hilo) и crash_rounds (Crash) в PostgreSQL. Хеш — VARCHAR(64), salt — VARCHAR(255).
  7. Когда раскрывается server_seed?
    • Keno/Hilo: сразу после завершения раунда (статус completed).
    • Crash: при переходе раунда в фазу crashed.
  8. Можно ли подменить результат между commit и reveal? Нет: любое изменение result или одной из солей даёт другой SHA-256 → расходится с ранее опубликованным хешем → виджет показывает fail при верификации.
  9. Нужен ли отдельный аудит / сертификат на Provably Fair? Нет обязательного. По индустрии iTech Labs выпускает PF-attestation за отдельные деньги и срок — [POLICY?] уточнить актуальный прайс/сроки. Полезно для маркетинга, не критично для запуска.
  10. Эмулированные ставки в LiveBets (бот-трафик) — ломают ли Provably Fair? Нет. Алгоритм для эмулированных ставок тот же, что и для реальных. Игрок не может отличить «настоящую» ставку от синтетической по виду PF-данных. Эмуляторы тоже верифицируются.
  11. Можно ли получить от нас open-source калькулятор верификации для встройки в их player area? Код verifyHash лежит в репозитории game-widget. [POLICY?] — даём ли формально под лицензию (MIT/Apache/proprietary)?
  12. Что отвечать на «Provably Fair — это маркетинг, нужен GLI»? Согласиться, что для регулируемых рынков GLI обязателен; PF — дополнение, не замена. Вернуть фокус: для крипто / sweepstakes / Curaçao мы готовы прямо сейчас, под MGA/UKGC встанем в очередь на сертификацию по результатам пилота.

4. Математика игр (RTP, волатильность, EV, hit frequency)

  1. RTP (Return to Player): теоретический процент ставок, возвращаемый игрокам в долгосрочной перспективе. RTP = Σ (P(i) × Payout(i)). House Edge = 100% − RTP.
  2. Какой RTP у наших игр? Per-operator конфигурируется в диапазоне 90.00%–99.99% через operator_game_settings.rtp. Default value в seed — 97% (стандарт для market fit с Aviator/Spribe).
  3. Кто решает RTP для конкретного рынка? Конфигурируется на стороне оператора. Мы НЕ навязываем фиксированное значение.
  4. Волатильность (variance): распределение выигрышей. low — частые мелкие, high — редкие крупные, medium — баланс. RTP остаётся тот же, меняется кривая.
  5. Какая волатильность у наших игр?
    • Поле volatility (low|medium|high, default medium) задаётся в operator_game_settings.
    • Реально используется только в Keno (через payout-таблицу per volatility-class — см. BR-K6 и math/keno.md).
    • [GAP] для Hilo и Crash влияние volatility на математику не документировано в product/math/, фактический эффект надо подтвердить по коду перед обсуждением с контрагентом.
  6. Hit frequency: доля раундов, заканчивающихся выигрышем. Для Crash при RTP 97% и cashout на 2.0× hit frequency = 48.5%. Для Keno (1 число) — 25%.
  7. EV (expected value): матожидание выигрыша игрока за раунд. EV = -House Edge. При RTP 97% EV = −3% от ставки. Контрагент это спросит, чтобы оценить вклад нашего контента в его GGR.
  8. Max win: per-operator, operator_game_settings.max_win. В seed default — $10 000 USD за раунд. Crash дополнительно ограничен max_multiplier (seed default 10000×). При высокой ставке max_win cap бьёт раньше max_multiplier.
  9. Min/max bet: per-operator, в USD; конвертируются в валюту игрока по курсу exchange-API. Seed default: min 0.10 / max 100.00 USD.
  10. Можем ли поднять max bet до high-roller уровня (тысячи USD)? Технически да — поле decimal(20,8). Бизнес-вопрос: max_win должен быть пропорционально выше, иначе high-roller проигрывает в EV из-за cap.
  11. Crash mathematic, формула: `crash_point = max(1.00, floor(RTP / random ×

100) / 100), гдеrandom` — uniform CSPRNG ∈ (0, 1]. При RTP 97%: P(crash = 1.00×) ≈ 3.96% (каждый ~25-й раунд instant crash).

  1. Hilo mathematic: infinite deck (равновероятные 1/13 на ранг), коэффициент = (RTP/100) × 13 / favourable_ranks. Truncate до 2 знаков (даёт ≤1% drift от заявленного RTP).
  2. Keno mathematic: payout-таблицы per (volatility, выбрано, совпадений), рассчитываются под целевой RTP через геометрическую серию. Max payout зависит от volatility и max_multiplier.
  3. Theoretical vs Actual RTP — как мониторим? Админский RTP Monitor (US-A31) сравнивает rtp_actual с rtp_theoretical per (operator, game, currency). [GAP] В MVP Запланировано — реально admin-эндпоинт ещё не реализован. Сегодня доступно через прямые запросы к БД / Grafana.
  4. На какой выборке actual RTP сходится к теоретическому? Минимум для reliable отчёта (из admin/reports.md): Keno/Hilo — 1k bets, Crash — 5k bets. На малых выборках высоковолатильные исходы (1000× в Keno при выборе 10) дают сильный drift.
  5. Что такое RGS (Remote Game Server) и где он у нас? RGS — backend, на котором живёт игровая логика и который оператор вызывает через wallet API. У нас RGS — это собственный сервис game-api (Go-backend, репозиторий 2xwet/game-api). Мы не на чужом RGS, не на платформе типа Stake Engine.

5. Каталог игр и контент

  1. Что у нас в каталоге?
    • Механики: Keno (1-10 чисел из 40), Hilo (предсказание карты), Crash (множитель с cash out).
    • Скины: Classic, Forest, Space, Original — каждая механика во всех 4 скинах.
    • Game IDs (12): classic-keno, forest-keno, space-keno, original-keno, classic-hilo, forest-hilo, space-hilo, original-hilo, poker-rush, arrow-shot, space-ball, origin-crash.
    • Архитектурно «механика + скин» — каждая комбинация регистрируется как отдельная игра (LEGO pattern в game-widget/src/games/).
  2. Чем наш Crash отличается от Aviator (Spribe), JetX (SmartSoft), Spaceman (Pragmatic), Cash or Crash (Evolution)?
    • 4 скина (rebrand под аудиторию: PokerRush — poker-сайты, ArrowShot — охотничья тема, SpaceBall — крипто, Origin — наш фирменный).
    • 2 ставки на раунд (slot_index ∈ {1, 2}) — больше action на одного игрока.
    • Provably Fair с двумя солями (без client seed).
    • White-label-friendly архитектура (механика отделена от скина).
  3. Кастомный скин под оператора (его арт, цвета, лого) — готовы? Технически да: «механика + скин» наша архитектура, скин не влияет на математику. Срок и цена — [POLICY?].
  4. Демо-режим / free play без авторизации — поддерживаем? [POLICY?] проверить в коде. Многие операторы требуют демо-режим для лобби-витрины («посмотреть как игра играет, прежде чем зарегистрироваться»).
  5. Mobile-трафик и адаптивность. Виджет — Preact + Tailwind с breakpoint'ом game-lg: 680px (см. game-widget/CLAUDE.md). iframe allow="fullscreen", percent-based CSS.
  6. Минимальные / целевые размеры окна? [POLICY?] — конкретных зафиксированных значений в product-документации нет.
  7. Поддерживаемые браузеры / OS-минимумы? [POLICY?] — typically iOS Safari N-2, Chrome N-2, Edge N-2; уточнить, что мы реально тестируем.
  8. Accessibility (WCAG 2.1 AA)? [POLICY?] — UKGC/MGA требуют. Сейчас ARIA-разметка в виджете есть базовая, формального аудита нет.
  9. Live dealer? Нет, только RNG-формат.
  10. Network jackpot / progressive jackpot? Нет в MVP. Crash — общий раунд для всех (общий множитель), но без jackpot-пула. Roadmap.
  11. Network tournaments / leaderboards аггрегатора — встраиваемся? Roadmap. У нас есть BetHistory (US-BH1-4) с PF-данными — основа для tournament feed; production API — Post-MVP.
  12. Free spins / freebets / bonus-money flag в Wallet API? [GAP] — флага is_free для бесплатных раундов сейчас нет; все ставки идут стандартным Debit. Hub88-style модель (отделение promo-ставок от GGR) — Roadmap.
  13. Bonus money / locked balance (отдельный счёт для бонусных средств) — поддерживаем разделение в Wallet API? [GAP] нет — оперируем единым балансом, который возвращает /authenticate.
  14. Частота релизов нового контента? [POLICY?] — не зафиксировано.
  15. Эксклюзивный контент под партнёра — готовы? [POLICY?] Технически да; срок exclusive, цена, condition — обсуждается case-by-case.
  16. Чат внутри виджета — есть, как модерируется? Чат изолирован per (operator_key, game_id) (BR-CH1). [GAP] модерация контента — встроенной фильтрации обсцентного / спама не реализовано (см. product/social/chat.md). Если оператор хочет — на его стороне или через roadmap-доработку.

6. Wallet API — критическая часть звонка

  1. Какой протокол Wallet API мы умеем сегодня?
    • Единственный реализованный адаптер: generic_hmac. Стандартный HMAC-SHA256 с shared secret в заголовке X-Signature, timestamp window 5 минут.
    • Другие адаптеры (Hub88-style RSA-2048, SOFTSWISS, Pragmatic, EveryMatrix) — [GAP] не реализованы. Требуют написания нового кода в payment_client/resolver.go. [POLICY?] на сроки и цену кастомного адаптера.
  2. Сколько операций в Wallet API? Пять, все POST: - /wallet/authenticate — валидация токена; возвращает {player_id, display_name, balance, currency}. - /wallet/balance — рефреш баланса. - /wallet/debit — списание ставки (идемпотентно по transaction_id). - /wallet/credit — зачисление выигрыша; Credit(0) обязателен при проигрыше для закрытия раунда. - /wallet/rollback — откат Debit при сетевом сбое после списания.
  3. Кто инициирует вызов? Провайдер → Казино (Wallet вызываем мы).
  4. Идемпотентность. Ключ — transaction_id (UUID v4) для Debit/Credit/Rollback. Повторный запрос с тем же ID возвращает тот же результат, без дублирования.
  5. Зачем Credit(0)? Закрывает раунд явно: без него раунд остаётся «открытым», возникают reconciliation-расхождения, оператор получает alert о незакрытых раундах.
  6. Что мы возвращаем в /authenticate? Один баланс одной валюты: {player_id, display_name, balance: "23.81", currency: "USD"}. Никакого массива balances[] — это ADR-002, выровнялись с Hub88 / Pragmatic / SOFTSWISS.
  7. Может ли оператор писать свой Wallet API под мульти-валюту? Да, но один launch = одна валюта = одна сессия. Чтобы переключить валюту, игрок возвращается в лобби и запускает новый launch с другим ?currency=. ADR-002.
  8. HMAC-формат подписи. HMAC-SHA256(secret, raw_request_body) в hex, заголовок X-Signature. Timestamp в X-Timestamp (Unix seconds), валидное окно 5 минут (защита от replay).
    • Critical: оператор валидирует подпись на raw body, БЕЗ JSON-десериализации/pretty-print (любая разница ломает signature).
  9. Можем ли поддержать RSA-SHA256 (Hub88-style)? [GAP] — не сегодня. Адаптация требует кода в payment_client/resolver.go (key pair exchange, signature verification на RSA). [POLICY?] срок и цена.
  10. Таймаут запроса к wallet'у. Per-operator в wallet_config.timeout_ms, default 5000 ms. Если 0 или не указан — берётся config.DefaultWalletTimeoutMS провайдера.
  11. Что если wallet недоступен во время Debit? Запрос ставки отклоняется, возвращается WALLET_ERROR. Игрок видит ошибку, может повторить. Crash-ставка переходит в терминальный debit_failed, слот освобождается (BR-CRASH9).
  12. Что если wallet недоступен после Debit (deadlock)? Через таймаут автоматически вызываем Rollback (с тем же transaction_id). Если Rollback тоже падает — раунд остаётся в pending до ручной reconciliation. [GAP] автоматизированный recovery (US-A25 runbook) — Post-MVP.
  13. Реконсиляция / сверка с оператором. Сегодня — manual через CSV-экспорт транзакций (/admin/v1/transactions/export). [GAP] эндпоинт не описан в OpenAPI (admin-api.yaml) — known limitation.
  14. Disputed transactions / chargebacks — кто обрабатывает? Оператор (платёжная сторона у него). Мы по запросу даём raw round-data + Provably Fair доказательства для конкретной ставки.
  15. Формат денежных сумм в Wallet API. Строки: "10.50", "0.000000000000000001". Не integer × 100000 (Hub88) и не int64 × 10⁶ (Stake Engine). Это упрощает мульти-валюту с разной precision (USD=2, BTC=8, ETH=18 wei). ADR-004.
    • [GAP] wallet-api.yaml сейчас декларирует pattern ^-?\d+(\.\d{1,8})?$ — расширим до \d{1,18} когда первая high-precision валюта попадёт в production.
  16. Какие коды ошибок возвращаем в Wallet API? INVALID_TOKEN, OPERATOR_NOT_FOUND, WALLET_ERROR, SIGNATURE_INVALID, INSUFFICIENT_FUNDS, CURRENCY_NOT_SUPPORTED, GAME_NOT_AVAILABLE, DUPLICATE_TRANSACTION, TRANSACTION_NOT_FOUND. Маппинг — в integration/ceo-call-checklist.md.

7. Launch Flow (как игрок попадает в игру)

  1. Как казино запускает игру? GET-redirect на наш URL: https://games.{наш-домен}/api/v1/games/{game_id}/launch?token={composite_token}&lang={locale}&currency={code}. [POLICY?] реальный production-домен подставляется в момент онбординга оператора.
  2. composite_token. Строка {operator_key}:{casino_token} через двоеточие. Мы парсим, извлекаем operator_key для роутинга, casino_token передаём в /wallet/authenticate казино. Без отдельного operator_id в query.
  3. Формат casino_token. На усмотрение оператора (UUID, JWT, session ID, base64). Мы не валидируем формат, только передаём.
  4. TTL casino_token. На усмотрение оператора. Рекомендуем ≤ 5 минут. После /authenticate мы создаём свою игровую сессию (TTL 24 часа), и оператор может инвалидировать casino_token сразу.
  5. Почему только iframe, не popup, не fullscreen redirect? postMessage между провайдером и казино обязателен (закрытие игры, обновление баланса). Без iframe нет родительского окна → postMessage не работает.
  6. Какие postMessage мы шлём? { "type": "GAME_CLOSE" } при закрытии игры игроком. Расширения (GAME_LOADED, BET_PLACED, BALANCE_UPDATED, RG_NOTIFICATION) — [GAP] roadmap.
  7. Параметр lang. Сейчас в виджете реально поддерживаются только en (default) и ru (см. game-widget/src/constants/languages.ts — массив из двух языков). Прочие — потребуют локализации (i18n bundle в public/locales/). [POLICY?] план языковой экспансии.
  8. Параметр currency. Любой код из currency_registry. Если оператор не передаёт — берётся default_currency оператора (см. ADR-002).
  9. Multiple devices / concurrent sessions. [POLICY?] проверить в коде. Что происходит, если игрок открыл одну игру в двух вкладках или на двух устройствах? Уникальность сессии в БД определяется ключом, надо подтвердить поведение.
  10. Round timeout при потере соединения. Instant (US-INS3): сессия восстанавливается, активный раунд продолжается, таймаута нет. Multiplayer Crash (BR-CRASH5): без auto-cashout ставка остаётся в раунде до краша.
  11. Закрытие игры — что должен делать оператор? Слушать postMessage с event.origin === "https://games.{наш-домен}", при GAME_CLOSE — закрыть iframe / показать лобби / refresh баланса.
  12. Deep link в конкретный раунд / replay? [GAP] нет. Replay через B2B history (US-INT9) — Post-MVP.

8. B2B API (server-to-server, не для игрока)

  1. Какие B2B endpoint'ы у нас сегодня?
    • GET /api/v1/games — каталог игр оператора (US-INT8). [GAP] сегодня эндпоинт публичный, без HMAC-валидации, RTP в ответе захардкожен 97%. Production-grade B2B вариант — Post-MVP.
    • GET /api/v1/players/{player_id}/rounds — история раундов (US-INT9). [GAP] в коде отсутствует. Целевая Post-MVP.
    • GET /api/v1/rounds/{round_id}/fairness — данные Provably Fair (US-INT10). [GAP] частично реализовано.
    • Critical для контрагента: наш B2B API сегодня сырой. Если нужен production-grade с подписью / фильтрами / пагинацией — это roadmap-блокер.
  2. Подпись B2B-запросов. Целевая: HMAC-SHA256 с тем же secret_key, что и Wallet API. Заголовки: X-Operator-Id (исторически — там operator_key, slug), X-Signature, X-Timestamp.
  3. История раундов — на какой период? Все завершённые раунды без автоматического срока хранения. PG-партиционирование — Post-MVP.
  4. Поля в истории раунда. Целевые: round_id, game_id, bet_amount, win_amount, created_at, status + Provably Fair данные (hash, server_seed, result).
  5. Webhooks на завершение раунда / ошибку wallet'а / алерт? [GAP] нет. Альтернатива — polling или общий мониторинг (Grafana / Loki). Roadmap.
  6. CSV / Parquet экспорт транзакций для оператора. Есть админский CSV через /admin/v1/transactions/export. [GAP] не описан в OpenAPI, под B2B контрагента не оптимизирован.
  7. Round details API. Crash: crash_point, кто и когда сделал cashout — отдаются через US-INT10 fairness endpoint + history. Lifecycle событий отдельным API нет, только в составе round summary.
  8. Data export при termination контракта (он уходит и забирает свою историю). [POLICY?] механизма автоматического экспорта нет; manual по запросу через CSV.

9. Безопасность

  1. TLS. TLS 1.2+ обязателен на наших endpoint'ах. Wallet оператора должен быть HTTPS (BR-C1). [GAP] на уровне кода HTTPS у клиента wallet'а не enforced — control на уровне provisioning'а оператора.
  2. IP whitelisting. [POLICY?] Сейчас не управляется через админку, только через инфра-конфиг.
  3. Static egress IPs нашего gateway (для whitelisting у оператора). [POLICY?] реальный диапазон IP — уточнить с инфра-командой перед передачей контрагенту.
  4. Replay attack protection. HMAC + timestamp window 5 минут. Replay вне окна отклоняется.
  5. Хранение wallet secret_key. В operators.wallet_config (JSONB) в открытом виде. [GAP] маскирования в GET /admin/v1/operators/{key} нет (см. admin/credentials.md). Шифрование через KMS / Vault — Post-MVP.
  6. Ротация секретов. Сегодня — через миграцию (re-seed wallet_config). Out-of-band (по почте / 1Password). US-A4 (rotation flow) удалена из MVP; workaround — деактивация + новый оператор.
  7. 2FA для админ-панели? Single admin (BR-ADM1), доступ через VPN/Bastion. [GAP] 2FA для UI — Post-MVP.
  8. Audit log админских действий? [GAP] нет — US-A18 отсутствует в коде. Если контрагент требует под compliance — roadmap-блокер.
  9. Что делаем при утечке secret_key? Деактивируем оператора (is_enable=false блокирует все запросы), создаём нового с другим operator_key (immutable BR-O1, тот же ключ переиспользовать нельзя), оператор переподключается. Болезненно — улучшение через rotation flow roadmap.
  10. Penetration test / bug bounty? [GAP] external pen-test не проводился. Есть внутренний линтинг (golangci-lint, staticcheck), архи- и dep-проверки. Готовы пройти за счёт контрагента перед go-live на регулируемом рынке.
  11. DDoS-защита. [POLICY?] уточнить актуальный stack (cloud LB / CDN), rate-limit middleware на критических endpoint'ах есть.

10. Real-time, iframe, mobile

  1. WebSocket-стек. Centrifugo (open-source). Абстрагируется как «Сервис реального времени» в API-контракте.
  2. Namespace'ы Centrifugo (см. game-widget/CLAUDE.md): livechat, livebets, online, user, crash. Каналы партиционированы по (operator_key, game_id, pool) — см. ADR-001.
  3. Tick rate в Crash. ~20 Hz (tick_interval = 50ms). Гибридная схема: серверные контрольные точки + клиентская интерполяция между ними.
  4. End-to-end latency для cashout. [ОРИЕНТИР] по индустрии цель — sub-100ms. [POLICY?] наши реальные замеры — в Grafana (grafana.2xwet.games), нужно сверить перед декларацией контрагенту.
  5. Reconnect logic. Instant (US-INS3): сессия восстанавливается, активный раунд продолжается. Multiplayer (US-MP1): WebSocket reconnect, snapshot текущего раунда + стрим событий с last seen position.
  6. iframe sandbox attributes. Сегодня в наших примерах указан только allow="fullscreen". [POLICY?] полный набор sandbox= атрибутов и CSP-инструкций для оператора — нужно зафиксировать перед документацией. Cross-origin postMessage → оператор обязан проверять event.origin.

11. Локализация и валюты

  1. Сколько валют поддерживаем? Любая из глобального currency_registry (manifest infra/currencies.yaml). На сегодня в манифесте: USD, EUR, GBP, RUB, BRL, MXN, INR, BTC, ETH, USDT, USDC + GC, SC (sweepstakes virtuals) + резервы XGC, XSC. Добавление — миграция манифеста с регенерацией codegen-артефактов.
  2. Стандарт кодов. ^[A-Z]{2,5}$ (ISO 4217 + крипто-расширения). [GAP] wallet-api.yaml декларирует строго ^[A-Z]{3}$ — валидирующие по spec'у строго wallet'ы отклонят USDT. Поправка спека — Post-MVP.
  3. Базовая валюта. USD (фиксированно). Лимиты ставок задаются в USD, конвертируются в валюту игрока по курсу exchange-API.
  4. Источник курсов обмена. Для MVP — exchange-api (free, без SLA). [POLICY?] переезд на платный fxRates / Open Exchange Rates — для крупных операторов критично.
  5. Частота обновления курсов. «Периодически по расписанию» (см. currencies.md). [POLICY?] конкретная cron-частота — уточнить по коду.
  6. Курс на момент транзакции сохраняется в transactions.exchange_rate (BR-CUR4) — историческая отчётность точная.
  7. Округление при конвертации. Truncate (обрезание) до precision валюты, не математическое округление (BR-CUR5). Защита от дробления и микро-арбитража.
  8. Поддержка крипто. BTC/ETH/USDT/USDC в манифесте. Wallet-протокол uniform (string decimals, precision-aware). Виджет нативно поддерживает precision ≥9 (ADR-004) — ETH wei работает.
  9. Языки UI. Реально в виджете сейчас два: en (default), ru (см. game-widget/src/constants/languages.ts). i18n через i18next с namespace'ами game, ui, tutorial. Расширение — добавить bundle в public/locales/{lang}/. [POLICY?] план языковой экспансии.

12. Sweepstakes / Pool model (US-специфика)

  1. Что такое sweepstakes-режим? US legal workaround: игроки покупают Gold Coins (GC) (для развлечения, не обмениваются на деньги) и БЕСПЛАТНО получают Sweeps Coins (SC) (можно redeemить на призы). Легально в большинстве штатов, но детали и AMOE-требования различаются по штатам (FL/WA полностью запрещают модель). Юридическую формулировку под конкретный штат уточняет оператор / его юрист.
  2. Поддерживаем ли мы sweepstakes? Да, через Pool classifier на currency: real | gold | sweeps. ADR-001. GC — pool=gold, SC — pool=sweeps, USD/BTC/EUR — pool=real.
  3. Изоляция pool'ов. Crash раунды партиционированы по (operator, game, pool). Игроки в GC видят только GC-активность, в SC — только SC, в real — только real. Каналы Centrifugo, livebets, чат — тоже per-pool.
  4. Compliance KYC / redemption / playthrough — на нашей стороне? Нет. ADR-001: «compliance остаётся ответственностью оператора — мы предоставляем игровую механику + payment contract».
  5. AMOE (Alternative Method of Entry). Способ получить SC бесплатно без покупки — обязательное требование sweepstakes-модели в большинстве US штатов, но реализуется на стороне оператора, не у нас.
  6. Можем ли работать с Stake.us / Chumba / LuckyLand-style операторами? Технически да. Pool model спроектирована именно под них (industry-aligned с LuckyStreak — абстракция свипса как обычной currency). Никакой спец-логики на нашей стороне не нужно.
  7. Один оператор, два pool'а одновременно. Да, через смену launch'а. Игрок в лобби выбирает «Play GC» или «Play SC» — разные launch URL с разным ?currency=. Виджет работает с одной валютой за сессию (no in-session switch — см. memory project_no_in_session_currency_switch).
  8. In-session currency switch — почему нет? Architectural decision. Индустриальный паттерн (Hub88, Pragmatic, SOFTSWISS). Упрощает state, нет race conditions при смене pool в середине Crash-раунда.

13. SLA, Uptime, поддержка

Весь раздел требует подтверждения CEO до первого внешнего обещания. В коде и доке формальных SLA-обязательств нет; всё ниже — вопросы для уточнения.

  1. Какой uptime гарантируем? [POLICY?] Industry baseline 99.9% (\[ОРИЕНТИР\]). Реальные данные за последние 90 дней — Grafana, нужно сверить.
  2. Maintenance window. [POLICY?] Деплои game-api rolling (zero-downtime); миграции БД через CREATE INDEX CONCURRENTLY (memory do_concurrent_migrations).
  3. RTO / RPO. [POLICY?] Не зафиксированы. Уточнить с инфра-командой.
  4. Backup-стратегия. [POLICY?] Уточнить (PG snapshot частота, WAL streaming, retention).
  5. Регион хостинга и DR-план. [POLICY?] Multi-region failover на сегодня нет — single-region. Уточнить, какой именно регион.
  6. Время реакции на P1 incident. [POLICY?] Industry baseline: P1 ack 30 мин / resolution 4 ч.
  7. Каналы поддержки. [POLICY?] обычно: email, dedicated Slack-channel с интегратором, on-call по WhatsApp/Telegram. Реальные контакты подставить.
  8. Документация для оператора. Публичный GitHub: 2xwet/docs (этот репозиторий), основной hub — integration/. OpenAPI spec в game-api/api/. Code examples (Node.js, Python) в examples/.
  9. Status page. [GAP] публичной нет. Сегодня — приватный Grafana-дэшборд (доступ по запросу).
  10. Metrics-API для оператора (он хочет видеть наш health в своём BI). [POLICY?] Не реализовано. Возможна выгрузка Prometheus-метрик через VPN — Post-MVP.
  11. Penalty при downtime / service credit. [POLICY?] Industry baseline: <99.5% → 10% credit, <99% → 25% credit. Наша позиция — требует подтверждения.

14. Sandbox, тестирование, сертификация интеграции

  1. Sandbox / staging environment. Есть (mirror prod-схемы с синтетическими операторами). [POLICY?] реальный production sandbox-домен подставляется в момент онбординга.
  2. Тестовые игроки. Оператор реализует тестовый wallet, мы делаем launch с любым casino_token — sandbox-wallet возвращает синтетического игрока с произвольным балансом.
  3. Скрипт автотестов интеграции. [GAP] Hub88-style suite из 27 автотестов нет. Сегодня — manual test plan + Postman collection (можем дать).
  4. Сколько занимает интеграция. [ОРИЕНТИР] по индустрии — 4-8 недель: ~1 неделя — wallet API, ~1 неделя — launch flow + iframe, ~2 недели — staging-тесты, ~1 неделя — production cut-over. Для нас может быть быстрее (простой generic_hmac) или дольше (если нужен кастомный адаптер).
  5. Кто пишет адаптер на стороне оператора? Оператор. Мы даём:
    • OpenAPI spec в game-api/api/wallet-api.yaml.
    • Working examples в Node.js + Python.
    • HMAC-валидацию sample.
    • Sandbox для дебага.
  6. Сертификация интеграции (а не самих игр) — нужна? Не обязательная сегодня. Если контрагент работает на регулируемом рынке — его лаборатория проверяет полный stack (наш + его). На Curaçao — обычно integration-test сами в режиме smoke.
  7. Версионирование API. URL-prefix /api/v1/. Breaking changes — v2/ с минимум 6 месяцев параллельной работы. [POLICY?] конкретный deprecation policy.
  8. Migration tools при breaking change. [GAP] автоматизированных нет. План: notification по email за N дней + помощь в миграции через dedicated канал.
  9. Тестовые данные для GLI/iTech (1B симуляция). Формула public, симулятор реализуется быстро. [POLICY?] готовы предоставить pre-computed dataset или live-симулятор on-demand.
  10. Load testing capacity. У нас есть выделенный sub-проект game-loadtest для нагрузочных тестов. [POLICY?] актуальный sustainable peak (RPS / concurrent users) — нужно поднять последний отчёт перед декларацией.

15. Reporting, BI, RTP monitoring

  1. Какие отчёты доступны оператору?
    • GGR Report (US-A28): GGR per-operator/game/currency/period, drill-down. ✅ Готово.
    • Transactions Report (US-A29): полный список с фильтрами, CSV-экспорт. [GAP] фильтры type/status/round_id сегодня игнорируются — known limitation.
    • Executive Dashboard (US-A30): KPI overview — Запланировано.
    • RTP Monitor (US-A31): actual vs theoretical — Запланировано.
    • System Health (US-A32): операционный статус — Запланировано.
  2. GGR vs NGR — что мы считаем? GGR (Total Bets − Total Wins). NGR — на стороне оператора (он вычитает свои bonuses / payment fees / taxes / наш rev-share).
  3. Метрики выдаём в каких единицах? Per-currency агрегаты + сводный USD по exchange_rate на момент транзакции (BR-REP3). Точная историческая отчётность.
  4. Real-time ли отчёты? GGR — near-real-time, читается прямо из PG. [POLICY?] конкретный lag — уточнить. RTP — near-real-time, но reliable только на больших выборках (см. minimum sample sizes в разделе 4).
  5. Доступ к raw data. Через CSV-экспорт. Чистый data warehouse / Parquet-export — Post-MVP. [POLICY?] для крупного контрагента возможна PeerDB-репликация в их BI.
  6. Anti-fraud / pattern detection. [GAP] дедикейтед anti-fraud системы у нас нет. Ответ: ответственность оператора (он видит deposit patterns, мы — только game patterns). По запросу даём bet_count / win_pattern per player для его системы.
  7. Налоговая отчётность. Не формируем (W-2G в US, EBA-формы в EU — на стороне оператора). GGR-выгрузка — да.
  8. Reconciliation при расхождении наших и его данных. Сегодня manual: оператор присылает discrepancy, мы сверяем по transaction_id. Automated reconciliation — Post-MVP.

16. Responsible Gaming (RG)

  1. Reality checks / time alerts в виджете? [GAP] нет. RG-инструменты на стороне оператора. Если регулятор контрагента требует — внедрять через postMessage от оператора («покажи reality check сейчас») — Post-MVP.
  2. Self-exclusion. Оператор не выдаёт casino_token excluded-игроку. Мы доверяем токену. Игрок, попавший в нашу сессию, доигрывается до конца раунда; следующий launch уже не пройдёт /authenticate.
  3. Deposit / loss limits в виджете? Нет. Лимиты на стороне оператора (его wallet возвращает INSUFFICIENT_FUNDS). Мы прокидываем ошибку в UI.
  4. Cooling-off period. Тот же механизм через token / wallet check.
  5. Минимальный возраст игрока. Оператор валидирует на регистрации / KYC. Мы получаем уже валидированного игрока.
  6. Если контрагент работает на UKGC/MGA и требует RG-инструменты в самом виджете — deal breaker сегодня без roadmap. См. раздел 24.

17. Коммерческие условия

Весь раздел [POLICY?]. В коде нет ни одной коммерческой ставки. Цифры ниже — индустриальный baseline для разговора, не наша утверждённая позиция.

  1. Rev-share. [ОРИЕНТИР] RNG-провайдеры — 7–20% от GGR; aggregators сверху берут 1–5%. [POLICY?] наша позиция, тиеры, зависимость от объёма.
  2. Минимальный гарантированный платёж (MGN). [POLICY?] Берём ли для входа? При каких условиях?
  3. Setup fee. [POLICY?] $0 для стандартного generic_hmac или платим за инженерные недели на кастомный адаптер?
  4. Период оплаты. [POLICY?] Net-30 — индустриальный стандарт, наша позиция требует подтверждения.
  5. Валюта платежей. [POLICY?] USD по умолчанию? EUR / USDT по запросу?
  6. Кто платит за конвертацию валют в платеже. [POLICY?]
  7. Минимальная сумма перевода. [POLICY?]
  8. Withholding taxes. [POLICY?] Зависит от юрисдикций обеих сторон + tax treaty.
  9. Бонусные ставки (freebets) в GGR. Hub88-модель: is_free flag, freebet НЕ идёт в GGR. У нас — [GAP] флага нет, все ставки идут в GGR. [POLICY?] как трактуем коммерчески до реализации флага.
  10. Промо-бонусы от провайдера (наши tournaments, free spins drops, prize pools). [POLICY?] Сегодня нет network promo инфраструктуры — обсуждается bespoke под крупного партнёра.
  11. Время до first payout. [POLICY?] Зависит от выбранного payment terms.
  12. Penalty / service credit при downtime. [POLICY?] см. раздел 13.

18. Бренд, контракт, эксклюзив

Большинство пунктов — [POLICY?]. В коде нет brand guidelines или contract templates — это юридический и продуктовый owner.

  1. Брендинг виджета. [POLICY?] Игра в нашем брендинге (логотип 2xwet)? White-label без нашего лого? За доплату или включено?
  2. Custom skin под оператора. Технически готовы (механика отделена от скина). [POLICY?] срок и цена.
  3. Exclusive title. Технически готовы. [POLICY?] период exclusive, цена, формат (MGN или upfront), что после периода — общий каталог?
  4. Co-marketing / co-PR. [POLICY?]
  5. Право использовать наш бренд в их маркетинге. [POLICY?] lobby (логотип, screenshot), promo materials, social media — каталог brand assets отдаётся через NDA.
  6. Срок контракта и notice period. [POLICY?]
  7. Termination clauses. [POLICY?] Material breach, repeated SLA failure, change of control, regulatory issue, insolvency. Транзишн-период для досживания активных сессий — обсудить.
  8. Force majeure / change of law. [POLICY?] Стандартные clause'ы.
  9. Indemnification. [POLICY?] Базовый принцип: мы — за IP infringement игрового контента и дефекты математики (RTP не соответствует declared); они — за compliance с регулятором их рынка (KYC, AML, RG, geo).
  10. Insurance (E&O / cyber). [POLICY?] Есть ли требование?

19. Roadmap, инновации

  1. Что в roadmap? Список приоритетов — [POLICY?], не зафиксирован в product/. На обсуждение CEO ставятся:
    • GLI/iTech-сертификация (срок и бюджет требуют решения).
    • Кастомные wallet-адаптеры (Hub88-style RSA, прочие — по запросу).
    • B2B API production-grade (signed, paginated, filtered).
    • Webhooks (round_completed, wallet_error).
    • Tournament infrastructure.
    • Freebet flag в Wallet API.
    • Audit log админских действий.
    • 2FA для админ-панели, KMS для secret_key.
  2. Новые механики в pipeline. [POLICY?] Не зафиксированы в product/.
  3. AI / personalization. Сегодня — pure RNG-математика, никакого AI-tuned RTP. Это плюс для регуляторов.
  4. Network jackpot / progressive. Roadmap для Crash. Идея: общий jackpot pool, ставка% идёт в pool, выигрывает при определённом множителе.
  5. Партнёрства с другими провайдерами. [POLICY?] Не блокируем. Открыты к интеграциям с другими content-makers, если контрагент — агрегатор.

20. Onboarding и операционка

  1. Технический проект-план. Совместно. Драфт от нас (мы знаем pace своего sandbox), final — оба подписывают. Tracker — Notion / Linear / GitHub project (любой удобный контрагенту).
  2. Кто наш integration manager? [POLICY?] Сегодня — фаундер/CTO напрямую. План dedicated роли — обсуждается.
  3. Кто их integration manager — запросить контакт у контрагента.
  4. Cadence синхронизаций. [ОРИЕНТИР] Weekly stand-up на 30 минут до go-live; switch to monthly после стабилизации.
  5. Documentation handoff в день №1. URL на integration/, OpenAPI spec, examples (Node.js + Python), staging credentials, sample HMAC test vectors, contact tree.
  6. Когда эскалация на CEO? SLA breach 2+ месяца подряд / коммерческий пересмотр / breaking change в protocol / dispute по reconciliation.
  7. Marketing launch. [POLICY?] Synced press release в день GA или silent rollout?

21. Что мы хотим узнать у интегратора (обратная due diligence)

Мы не просто продавец, мы партнёр. Нужно знать, во что подписываемся.

  1. Их wallet-протокол точно. Hub88 RSA-2048 / SOFTSWISS / Pragmatic SOAP / custom? Если кастомный — оценить days-to-implement.
  2. Их требования по сертификации (GLI / iTech / BMM / нет / только наш PF).
  3. На каких рынках они нас распространят (страны, юрисдикции).
  4. Сколько активных операторов в их сети, какие крупнейшие.
  5. Traffic-прогноз: ставок/раундов в день в первый месяц / квартал / год? — От этого зависит, нужна ли scale-out нашей инфры.
  6. Их rev-share модель vs наша: где встречаемся в середине?
  7. Min payout к нам. Когда первый чек?
  8. Эксклюзивность. Они требуют от нас exclusive, либо они dual-supply со Spribe / SmartSoft / Pragmatic?
  9. Compliance-команда на их стороне. Кто, что они требуют от нас (DPA, AUP, content policy, RG-обязательства).
  10. Их red flags для нас. Чёрный список рынков, контентная политика (mature/age, branded IP, политика по minorities representation).
  11. Финансовая стабильность. Где инкорпорированы, parent company, audit-данные открыты? Риск bankruptcy в течение контракта?
  12. Контракт-template. Их или наш на старте? Чьи юристы драфтят?
  13. Диспьют-резолюшн. Какой суд / арбитраж в контракте? London / Stockholm / Singapore — индустриальный стандарт; контрагент может настаивать на своей юрисдикции.
  14. Insurance. Есть ли у них E&O / cyber-insurance, требуют ли от нас?

22. Агрегатор vs прямой оператор: специфика

  1. HMAC-подпись от чьего имени.
    • Прямой оператор: подпись на wallet/* и B2B-вызовы — его secret_key, известный только нам и ему.
    • Агрегатор: подпись агрегатора. Конечные казино внутри агрегатора нам неизвестны на уровне HMAC — мы видим только operator_key агрегатора.
  2. operator_key для агрегатора. Один operator_key на весь агрегатор или separate per end-casino? [POLICY?] — зависит от модели агрегатора (Hub88 — separate subpartner_id per end-casino; SOFTSWISS — варьируется). Влияет на reporting и изоляцию данных.
  3. Reporting через агрегатор.
    • Если один operator_key — агрегаты приходят на агрегатора, он сам split'ит per end-casino.
    • Если separate — мы выдаём per-casino.
    • [POLICY?] какую модель поддерживаем сегодня (наш operators table — single-tenant per operator_key, без понятия sub-tenant).
  4. Чат и Centrifugo каналы через агрегатора. Изоляция per (operator_key, game_id). Если один operator_key на много end-casinos — игроки из разных казино оператора будут в одном чате. [GAP] sub-operator isolation — Post-MVP.
  5. Контракт через агрегатора — с кем именно? С агрегатором (он — intermediary), не с конечным казино. Compliance-liability flow: end-casino → агрегатор → мы. [POLICY?] Indemnification — они должны закрыть нас от issues end-casinos.
  6. Pricing через агрегатор. Наш rev-share через агрегатор обычно ниже чем direct (агрегатор берёт свой кусок поверх). [ОРИЕНТИР] direct 15% / via aggregator 10–12%.
  7. Скорость онбординга через агрегатор. [ОРИЕНТИР] Hub88 обещает 3 дня (если у нас уже есть Hub88-compatible адаптер). Без адаптера — наша работа.
  8. Почему через агрегатор может быть выгоднее. Один контракт → доступ в десятки/сотни end-casinos. Маркетинг и техподдержка — на стороне агрегатора. Нам не надо подписывать N юр-договоров.

23. Deal breakers (когда НЕ берёмся)

  1. Регулируемые рынки US (Nevada / NJ / MI / PA), требующие GLI-19 до подписания. У нас сертификации нет. Курс на сертификацию занимает минимум 1-2 квартала + €15-40k за RNG-цикл — заранее декларируем.
  2. UKGC / MGA с требованием полного RG-инструментария в виджете (reality checks, time/loss limits inline). У нас в виджете этого нет, а прокидка через postMessage — Post-MVP.
  3. Контрагенты, требующие 99.99% SLA сразу в день подписания. Мы можем прозрачно показать наши реальные метрики и обсудить service credits, но гарантировать 99.99% в момент go-live — нет.
  4. Контрагенты, не желающие подписывать NDA до раскрытия secrets.
  5. Операторы в санкционных юрисдикциях или с операционной деятельностью в OFAC-список странах.
  6. Контрагенты с плохой репутацией на AskGamblers / Casinomeister / Casino Guru (постоянные жалобы на невыплаты, history of license revocations).
  7. Контрагенты, требующие audit log админских действий (PCI-style). [GAP] US-A18 не реализован. Honest red flag — заранее.
  8. Контрагенты, требующие 2FA админ-панели и KMS-хранение secret_key. [GAP] оба — Post-MVP.

24. Сложные вопросы и красные флаги (как отвечать)

Если контрагент задаёт это — будь готов. Если не задаёт — лучше предложить честную позицию сам, не пытаясь скрыть.

  1. «У вас есть GLI?» → Нет. Provably Fair как cryptographic substitute. Готовы получить под их рынок — обсудим распределение стоимости.
  2. «У вас есть B2B-лицензия?» → Нет на момент разговора. Готовы обсуждать получение под их условия (Anjouan дешевле, Curaçao — стандарт).
  3. «Какой процент игр у вас прошёл RNG-тест?» → Ноль. PF — наш механизм для тех же проблем. На регулируемые рынки — план сертификации с понятными датами после квартала пилота.
  4. «Покажите live RTP за 30 дней — он совпадает с заявленным?» → Покажем выгрузку. При расхождении — объясним sample size (Crash на малых выборках высоковариативный, см. min sample sizes из раздела 4).
  5. «Что если ваш wallet-адаптер сломает наш кошелёк?» → Изоляция per-operator: wallet-вызовы идут с per-operator secret_key, sandbox-этап исключает большинство issues. Production rollback план: deactivate operator (is_enable=false) блокирует все запросы за секунды.
  6. «Есть ли у вас live-референсы / case studies?» → [POLICY?] — зависит от того, есть ли уже подписанные операторы. Если нет — честно сказать, что мы early-stage и ищем pilot-партнёра.
  7. «Сколько у вас сотрудников / R&D-команда?» → Маленькая команда. Это И плюс (responsiveness, прямой канал на CEO), И минус (bus factor). Компенсация: прозрачная кодобаза в публичных репозиториях, документация на GitHub, готовность зафиксировать SLA в контракте.
  8. «Что если регулятор постучится к нам и попросит данные ваших игроков?» → Мы не храним PII (только player_id, display_name, история ставок). Regulator обращается в первую очередь к оператору (он держит KYC). Наша часть — round data + math compliance — отдадим по subpoena.
  9. «Что если игрок жалуется на проигрыш и подозревает читерство?» → Provably Fair — самозащита. В виджете кнопка Verify показывает, что хеш совпал. Если жалоба эскалируется — отдаём raw round data для независимой перепроверки.
  10. «Чего ВАМ не хватает в нашей платформе для интеграции?» → Готовый список уважаемых wallet-протоколов; production B2B API (signed, paginated); webhook infrastructure; freebet flag; tournament-feed API; audit log; KMS для secret_key.
  11. «Кто несёт ответственность, если игрок выигрывает $100k и оператор не может выплатить?» → Мы не платим выплаты — оператор несёт ликвидность игрока. Наш контракт оператора с нами касается только rev-share от GGR; volатильность выплат — risk оператора.

Связанные документы