Як казино підключає 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 до допуску до ставок, аудит-лог.

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

Імпорт столів і профілів лімітів, маппінг по країнах/валютах/КУС.
Гаряче оновлення лімітів і статусів столів.

Фронтенд

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 за рахунок ідемпотентності, строгих лімітів і чіткої спостережуваності.