How a casino connects live providers via bridge

What is bridge in the context of a live casino

Bridge is a layer between the operator's platform and live providers (Evolution, Pragmatic Live, Ezugi, TVBet, etc.) that normalizes APIs, events, logging and financial calculations. Simply put, bridge makes a dozen different integrations "seemingly" the same: a single betting contract, a single round status scheme, monotonous webhooks and reporting.

Why is it needed

A single contract for dozens of providers (fewer platform changes).

Idempotence and protection against takes (network retrays, reconnect player).

Catalog normalization (tables, limits, side-bets, locales).

Single cash desk and risk rules (limits, AML/KYT, RG).

Monitoring QoS stream and SLA by provider.

Chain of components

1. Casino Platform (host): accounts, KYC/RG, bonuses, wallet, front.

2. Bridge: provider adapters, event bus, table/limit mapping, financial accounting, logging, webhooks.

3. Live-Provider: stream (usually WebRTC/HLS), game engine, outcome calculation, dealers.

4. Wallet: Seamless (balance stored by the operator) or Transfer (deposit to the game bank from the provider).

5. Observability: stream metrics (FPS, RTT, buffer), business metrics (Bet, GGR, Hold).

Network protocols and sessions

Video:

WebRTC - low latency (100-500 ms), ICE/STUN/TURN required.
HLS/LL-HLS - higher delay, but simpler CDN.
Bets and events: WebSocket/HTTP-SSE/REST.
Tokens: short-lived JWT/opaque (TTL 3-10 min), rotation at the provider's request.

Wallet models

1) Seamless wallet (recommended)

The bet/payment goes through the bridge to the operator's wallet.

Pros: unified balance, instant limit control, simplified RG.

Cons: Strict wallet affordability (SLA) requirements.

2) Transfer wallet

The player transfers funds to the "table bank" at the provider.

Pros: less load on the operator's wallet during peaks.

Cons: harder returns, reconcile and AML control, friction in UX.

Session life cycle (seamless)

1 ./createSession → bridge creates' sessionId ', returns' streamUrl ',' betSocketUrl '.

2. The front opens the player (WebRTC/HLS) and the event connection.

3. The player bets → 'placeBet' in bridge ('idempotencyKey', 'roundId', 'selection', 'stake').

4. Bridge pre-authorizes the amount (hold) in the wallet → confirms to the provider.

5. The provider declares' bettingClosed '→ spin/deal →' roundResult '.

6. Bridge calculates payout, writes off/returns hold, generates' transactionId '.

7. Bridge sends a webhook to the platform ('roundId', 'result', 'payout', 'balanceAfter'), writes to the ledger.

8. Termination/reconnection - by 'sessionId' (idempotent).

Event contract (example)

→ bridge rate (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 response:

json
{
"status":"accepted",  "balanceHold":"-5. 00",  "betId":"bet_9f2…",  "effectiveLimits":{"maxBet":"5000. 00"}
}

Result of the → platform round (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"
}

Key rules:

All requests with'idempotencyKey '.
Clear typing of outcomes: 'WIN/LOSE/PUSH/VOID/RETRY'.
Stable identifiers: 'roundId' is globally unique (table + time + shard).

Catalogue and limits

Discovery: '/providers/: id/tables' - table list, limits, side-bets, languages, schedule.

Limit pools: 'DEFAULT', 'VIP _ A', 'VIP _ B', 'Ultra'.

Country/currency/KYC status mapping rules → allowed tables and limit profiles.

Hot limit change: 'limits' events. update 'without restarting the table.

Stream observability and quality (QoS)

Metrics by player:

RTT of bet signals (target <150 ms WebRTC).
Dropped frames / buffer events.
Bitrate/Resolution adaptation.
Bet window latency (time between 'bettingOpen' and the actual acceptance of the bet).

Metrics by provider/table:

Uptime of the table, aborted rounds, late settlements, frequency 'VOID'.
Average time-to-settle after rates close.
QoS alerts: FPS degradation, 'retry' spikes.

Compliance and safety

KYT/AML: analysis of deposit sources, "high risk" flag → ban on live bets.

RG (responsible game): timeouts, limits, self-exclusion - applied before 'placeBet'.

Data residency: logic and PII are stored by the operator; bridge stores only those logs and aggregates.

Transport security: mTLS/IP-whitelist to providers, HMAC request signature, short TTL tokens.

Audit: ledger immutable (WORM/append-only), export by 'roundId '/' sessionId'.

Settlement, reconcile and returns

On-the-fly settle: instant debit/credit for each outcome.

Batch reconcile: reconciliation of provider reports (hourly/daily) with the bridge ledger (P&L, commission).

VOID/REFUND scenarios: stream failure, dealer error, dispute - partial/full return with clear cause codes.

Dispute-center: a bunch of'roundId '↔ recording a video (timecode) so that support quickly solves tickets.

Performance and fault tolerance

Scaling: stateless provider adapters + Kafka/NATS as an event bus.

Storage: hot (Redis) for sessions/limits, warm (Postgres) for ledger, cold (S3) for logs.

Folbacks: if the wallet does not answer - 'SOFT _ DECLINE' with retras; if the provider is not available - turn off the tables/hide in the lobby.

Idempotent retrays: it is safe to repeat 'placeBet '/' settle' over network timeouts.

UX: frontend patterns

Clock synchronization: Use 'serverTime' from bridge for 'Close bets through....' timers

Localization: dealer language ≠ interface language; show subtitles/glossary of terms.

Stream player: auto-fallback WebRTC → LL-HLS with a bad network.

Error UI: clear codes ('LBRG-401 TOKEN_EXPIRED',' LBRG-429 LIMIT_EXCEEDED', 'LBRG-503 PROVIDER_DOWN').

Multi-table: fast switch tables without breaking the session (reuse 'sessionId').

Anti-patterns

Store long-lived tokens on the client.

Accept bid after 'bettingClosed' due to deal - dispute guaranteed.

Absence of'idempotencyKey '→ duplicates in retrays.

Mix time-zones in'roundId 'and reports.

Set limits "by eye" without profiles and KYC status.

Ignore stream QoS - high churn on mobile networks.

Step-by-step implementation plan (checklist)

Architecture and Contracts

Fix a single event contract: 'bet. place`, `bet. accepted`, `bet. rejected`, `round. settle`, `limits. update`, `session. close`, `provider. error`.
Define idempotency and formats' roundId ',' betId ',' transactionId '.
Select the wallet model (Seamless priority).

Safety

mTLS to providers, HMAC signature webhooks, TTL token ≤ 10 minutes.
Policy RG/AML/KYT before admission to rates, audit log.

Catalogue and limits

Import tables and limit profiles, mapping by country/currency/ACC.
Hot update of limits and table statuses.

Frontend

WebRTC player with LL-HLS folback, sync clock, stable bet timers.
Error codes and human-readable messages.

Test plan

High-latency/packet-loss scripts, reconnection without losing bid.
Double click bid → one debit (idempotency).
VOID/REFUND, disputed rounds, discrepancies in reports.

Observability

Дашборд QoS: RTT, dropped frames, aborted rounds, time-to-settle.
Alerts by SLA provider, reconcile reports.

Bridge turns the live integration zoo into a managed system: uniform rates, uniform calculations, predictable UX and transparent stream quality control. With a properly designed bridge, the operator connects new live providers faster, reduces technological risks and protects P&L through idempotency, strict limits and clear observability.