Как казино подключает live-провайдеров через bridge

Что такое bridge в контексте live-казино

Bridge — это прослойка между платформой оператора и live-провайдерами (Evolution, Pragmatic Live, Ezugi, TVBet и др.), которая нормализует API, события, логирование и финрасчёты. Проще говоря, bridge делает десяток разных интеграций «на вид» одинаковыми: единый контракт ставок, единая схема статусов раундов, однообразные webhooks и отчётность.

Зачем он нужен

Единый контракт для десятков провайдеров (меньше изменений в платформе).

Идемпотентность и защита от дублей (сетевые ретраи, reconnect игрока).

Нормализация каталога (таблицы, лимиты, side-bets, локали).

Единая касса и риск-правила (лимиты, AML/KYT, RG).

Мониторинг QoS стрима и SLA по провайдерам.

Цепочка компонентов

1. Casino Platform (хост): аккаунты, KYC/RG, бонусы, кошелёк, фронт.

2. Bridge: адаптеры провайдеров, bus событий, маппинг столов/лимитов, финрасчёт, логирование, webhooks.

3. Live-Provider: стрим (обычно WebRTC/HLS), игровой движок, расчёт исходов, дилеры.

4. Кошелёк: Seamless (баланс хранится у оператора) или Transfer (депозит в банк игры у провайдера).

5. Наблюдаемость: метрики стрима (FPS, RTT, буфер), бизнес-метрики (Bet, GGR, Hold).

Сетевые протоколы и сессии

Видео:

WebRTC — низкая задержка (100–500 мс), требуется ICE/STUN/TURN.
HLS/LL-HLS — выше задержка, но проще CDN.
Ставки и события: WebSocket/HTTP-SSE/REST.
Токены: короткоживущие JWT/opaque (TTL 3–10 мин), ротация по требованию провайдера.

Модели кошелька

1) Seamless wallet (рекомендуется)

Ставка/выплата идут через bridge в кошелёк оператора.

Плюсы: единый баланс, мгновенный контроль лимитов, упрощённый RG.

Минусы: строгие требования к доступности кошелька (SLA).

2) Transfer wallet

Игрок переводит средства в «банк стола» у провайдера.

Плюсы: меньше нагрузка на кошелёк оператора во время пиков.

Минусы: сложнее возвраты, reconcile и AML-контроль, трение в UX.

Жизненный цикл сессии (seamless)

1. /createSession → bridge создаёт `sessionId`, возвращает `streamUrl`, `betSocketUrl`.

2. Фронт открывает плеер (WebRTC/HLS) и соединение событий.

3. Игрок делает ставку → `placeBet` в bridge (`idempotencyKey`, `roundId`, `selection`, `stake`).

4. Bridge пред-авторизует сумму (hold) в кошельке → подтверждает провайдеру.

5. Провайдер объявляет `bettingClosed` → spin/deal → `roundResult`.

6. Bridge рассчитывает выплату, списывает/возвращает hold, генерирует `transactionId`.

7. Bridge шлёт webhook платформе (`roundId`, `result`, `payout`, `balanceAfter`), пишет в леджер.

8. Завершение/повторное подключение — по `sessionId` (идемпотентно).

Контракт событий (пример)

Ставка → bridge (WS/REST):

json
{
"type": "bet.place",  "idempotencyKey": "c0a4-77f…",  "sessionId": "sess_abc123",  "roundId": "R-2025-10-17-18:45:03-Table23",  "selection": [{"market":"roulette_straight","value":"17"}],  "stake": {"amount":"5.00","currency":"EUR"},  "limitsProfile":"VIP_A"
}

Ответ bridge:

json
{
"status":"accepted",  "balanceHold":"-5.00",  "betId":"bet_9f2…",  "effectiveLimits":{"maxBet":"5000.00"}
}

Результат раунда → платформа (webhook):

json
{
"event":"round.settle",  "roundId":"R-2025-10-17-18:45:03-Table23",  "bets":[
{"betId":"bet_9f2…","stake":"5.00","payout":"180.00","outcome":"WIN"}
],  "transactions":[
{"id":"trn_bet_9f2…","type":"DEBIT","amount":"5.00"},   {"id":"trn_pay_9f2…","type":"CREDIT","amount":"180.00"}
],  "balanceAfter":"1320.40"
}

Ключевые правила:

Идемпотентность: все запросы с `idempotencyKey`.
Чёткая типизация исходов: `WIN/LOSE/PUSH/VOID/RETRY`.
Стабильные идентификаторы: `roundId` глобально уникален (таблица+время+шард).

Каталог и лимиты

Discovery: `/providers/:id/tables` — список столов, лимиты, side-bets, языки, расписание.

Пулы лимитов: `DEFAULT`, `VIP_A`, `VIP_B`, `Ultra`.

Правила маппинга: страна/валюта/статус KYC → допустимые столы и профили лимитов.

Горячая смена лимитов: события `limits.update` без перезагрузки стола.

Наблюдаемость и качество стрима (QoS)

Метрики по игроку:

RTT сигналов ставок (цель < 150 мс WebRTC).
Dropped frames / buffer events.
Bitrate/Resolution адаптация.
Bet window latency (время между `bettingOpen` и фактическим принятием ставки).

Метрики по провайдеру/столу:

Аптайм стола, aborted rounds, late settlements, частота `VOID`.
Средний time-to-settle после закрытия ставок.
QoS алерты: деградация FPS, всплески `retry`.

Комплаенс и безопасность

KYT/AML: анализ источников депозита, флаг «высокий риск» → запрет на ставки в live.

RG (ответственная игра): тайм-ауты, лимиты, самоисключение — применяются до `placeBet`.

Data residency: логика и PII хранятся у оператора; bridge хранит только тех. журналы и агрегаты.

Transport security: mTLS/IP-whitelist к провайдерам, подпись запросов HMAC, короткий TTL токенов.

Аудит: леджер неизменяемый (WORM/append-only), экспорт по `roundId`/`sessionId`.

Расчёт, reconcile и возвраты

On-the-fly settle: мгновенные дебет/кредит по каждому исходу.

Batch reconcile: сверка отчётов провайдера (hourly/daily) с леджером bridge (P&L, комиссионка).

VOID/REFUND сценарии: сбой стрима, ошибка дилера, спор — частичный/полный возврат с чёткими кодами причин.

Dispute-центр: связка `roundId` ↔ запись видеофида (тайм-код), чтобы поддержка быстро решала тикеты.

Производительность и отказоустойчивость

Скалирование: stateless-адаптеры провайдеров + Kafka/NATS как шина событий.

Хранилища: горячее (Redis) для сессий/лимитов, тёплое (Postgres) для леджера, холодное (S3) для логов.

Фолбэки: если кошелёк не отвечает — `SOFT_DECLINE` с ретраями; если провайдер недоступен — отключить столы/скрыть в лобби.

Идемпотентные ретраи: по сетевым таймаутам повторять `placeBet`/`settle` безопасно.

UX: фронтенд-паттерны

Синхронизация часов: используйте `serverTime` от bridge для таймеров «Закрытие ставок через …».

Локализация: язык дилера ≠ язык интерфейса; показывайте субтитры/глоссарий терминов.

Стрим-плеер: auto-fallback WebRTC → LL-HLS при плохой сети.

Error UI: понятные коды (`LBRG-401 TOKEN_EXPIRED`, `LBRG-429 LIMIT_EXCEEDED`, `LBRG-503 PROVIDER_DOWN`).

Многотабличность: быстрый свич столов без разрыва сессии (reuse `sessionId`).

Анти-паттерны

Хранить долгоживущие токены на клиенте.

Принять ставку после `bettingClosed` из-за дилея — спор гарантирован.

Отсутствие `idempotencyKey` → дубли при ретраях.

Миксовать time-zones в `roundId` и отчётах.

Ставить лимиты «на глаз» без профилей и KYC-статуса.

Игнорировать QoS стрима — высокий churn на мобильных сетях.

Пошаговый план внедрения (чек-лист)

Архитектура и контракты

Зафиксировать единый контракт событий: `bet.place`, `bet.accepted`, `bet.rejected`, `round.settle`, `limits.update`, `session.close`, `provider.error`.
Определить idempotency и форматы `roundId`, `betId`, `transactionId`.
Выбрать модель кошелька (Seamless приоритетно).

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

mTLS к провайдерам, HMAC-подпись webhooks, TTL токена ≤ 10 минут.
Политика RG/AML/KYT до допуска к ставкам, аудит-лог.

Каталог и лимиты

Импорт столов и профилей лимитов, маппинг по странам/валютам/KYC.
Горячее обновление лимитов и статусов столов.

Фронтенд

WebRTC плеер с LL-HLS фолбэком, часы синхронизации, стабильные таймеры ставок.
Error-коды и человекочитаемые сообщения.

Тест-план

High-latency/packet-loss сценарии, reconnection без потери ставки.
Двойной клик ставки → один дебет (идемпотентность).
VOID/REFUND, спорные раунды, расхождения отчётов.

Наблюдаемость

Дашборд QoS: RTT, dropped frames, aborted rounds, time-to-settle.
Алерты по SLA провайдера, отчёты reconcile.

Bridge превращает «зоопарк» live-интеграций в управляемую систему: единые ставки, единые расчёты, предсказуемый UX и прозрачный контроль качества стрима. С правильно спроектированным bridge оператор быстрее подключает новых live-провайдеров, снижает технологические риски и защищает P&L за счёт идемпотентности, строгих лимитов и чёткой наблюдаемости.