Wie ein Casino Live-Anbieter über eine Brücke verbindet

Was ist Bridge im Live-Casino-Kontext

Bridge ist eine Schicht zwischen der Plattform des Betreibers und den Live-Anbietern (Evolution, Pragmatic Live, Ezugi, TVBet usw.), die APIs, Ereignisse, Logging und Finrashes normalisiert. Einfach ausgedrückt, macht Bridge ein Dutzend verschiedener Integrationen „nach Art“ gleich: einen einzigen Wettvertrag, ein einziges Schema von Rundenstatus, monotone Webhooks und Berichterstattung.

Warum er gebraucht wird

Ein einziger Vertrag für Dutzende von Anbietern (weniger Änderungen an der Plattform).

Idempotenz und Schutz vor Takes (Netzwerk-Retrays, Spieler-Reconnect).

Normalisierung des Verzeichnisses (Tabellen, Limits, Side-Bets, Locals).

Einheitliche Kassen- und Risikoregeln (Limits, AML/KYT, RG).

Überwachung von Stream-QoS und SLAs nach Anbieter.

Komponentenkette

1. Casino Platform (Host): Konten, KYC/RG, Boni, Wallet, Front.

2. Bridge: Provider-Adapter, Event-Bus, Tisch-/Limit-Mapping, Finanzbuchhaltung, Logging, Webhooks.

3. Live-Provider: Stream (in der Regel WebRTC/HLS), Spiel-Engine, Berechnung der Ergebnisse, Händler.

4. Geldbörse: Seamless (das Guthaben wird vom Betreiber gehalten) oder Transfer (Einzahlung bei der Spielbank beim Anbieter).

5. Beobachtbarkeit: Streammetriken (FPS, RTT, Puffer), Geschäftsmetriken (Bet, GGR, Hold).

Netzwerkprotokolle und Sitzungen

Video:

WebRTC - geringe Latenz (100-500 ms), ICE/STUN/TURN erforderlich.
HLS/LL-HLS - höhere Latenz, aber einfacheres CDN.
Preise und Veranstaltungen: WebSocket/HTTP-SSE/REST.
Token: kurzlebige JWT/opaque (TTL 3-10 min), Rotation auf Anfrage des Anbieters.

Brieftaschenmodelle

1) Nahtlose Geldbörse (empfohlen)

Die Wette/Auszahlung geht über die Brücke in die Wallet des Betreibers.

Vorteile: einheitliche Balance, sofortige Grenzkontrolle, vereinfachte RG.

Nachteile: strenge Anforderungen an die Portemonnaie-Verfügbarkeit (SLA).

2) Transfer wallet

Der Spieler überweist Gelder an die „Tischbank“ beim Anbieter.

Vorteile: Weniger Belastung für den Geldbeutel des Betreibers während der Spitzen.

Nachteile: schwieriger Retouren, reconcile und AML-Kontrolle, Reibung in UX.

Sitzungslebenszyklus (seamless)

1./createSession → bridge erstellt 'sessionId', gibt 'streamUrl', 'betSocketUrl' zurück.

2. Die Front öffnet den Player (WebRTC/HLS) und die Verbindung der Ereignisse.

3. Der Spieler setzt → 'placeBet' in Bridge (' idempotencyKey', 'roundId', 'selection', 'stake').

4. Bridge autorisiert den Betrag (Hold) im Wallet → bestätigt dies dem Anbieter.

5. Der Anbieter kündigt "bettingClosed" → spin/deal → "roundResult' an.

6. Bridge berechnet die Auszahlung, schreibt den Hold ab/gibt ihn zurück, generiert eine' transactionId'.

7. Bridge schickt einen Webhook an die Plattform ('roundId', 'result', 'payout', 'balanceAfter'), schreibt an den Ledger.

8. Vervollständigung/Wiederverbindung - durch 'sessionId' (idempotent).

Veranstaltungsvertrag (Beispiel)

→ 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"
}

Die Antwort der Brücke:

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

Ergebnis der Runde → Plattform (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"
}

Die wichtigsten Regeln:

Idempotenz: alle Anfragen mit 'idempotencyKey'.
Klare Typisierung der Ergebnisse: 'WIN/LOSE/PUSH/VOID/RETRY'.
Stabile IDs: 'roundId' ist global eindeutig (Tabelle + Zeit + Shard).

Katalog und Grenzen

Discovery: '/providers/: id/tables'- Tischliste, Limits, Side-Bets, Sprachen, Zeitplan.

Limitpools: „DEFAULT“, „VIP _ A“, „VIP _ B“, „Ultra“.

Mupping-Regeln: Land/Währung/KYC-Status → gültige Tische und Limitprofile.

Heißer Grenzwechsel: Ereignisse' Grenzen. update' ohne Neustart des Tisches.

Beobachtbarkeit und Qualität des Streams (QoS)

Metriken nach Spieler:

RTT der Wettsignale (Ziel <150 ms WebRTC).
Dropped frames / buffer events.
Bitrate/Auflösung Anpassung.
Bet window latency (Zeit zwischen 'bettingOpen' und der tatsächlichen Annahme der Wette).

Metriken nach Anbieter/Tisch:

Tabelle aptame, aborted rounds, late settlements, Frequenz' VOID'.
Die durchschnittliche Zeit-zu-settle nach dem Schließen der Wetten.
QoS-Warnungen: FPS-Abbau, „Retry“ -Spitzen.

Compliance und Sicherheit

KYT/AML: Analyse der Einzahlungsquellen, Kennzeichnung „hohes Risiko“ → Verbot von Live-Wetten.

RG (Responsible Game): Timeouts, Limits, Selbstausschluss - gelten bis' placeBet'.

Datenresidenz: Logik und PII werden vom Operator gespeichert; bridge speichert nur tech. Zeitschriften und Aggregate.

Transportsicherheit: mTLS/IP-Whitelist zu den Anbietern, Signatur der HMAC-Anfragen, kurze TTL der Token.

Audit: Ledger unveränderlich (WORM/append-only), Export über 'roundId '/' sessionId'.

Berechnung, Reconcile und Retouren

On-the-fly-settle: sofortige Belastung/Gutschrift für jedes Ergebnis.

Batch reconcile: Abgleich der Berichte des Anbieters (hourly/daily) mit dem Bridge Ledger (P&L, Provision).

VOID/REFUND-Szenarien: Stream-Absturz, Dealer-Fehler, Streit - teilweise/vollständige Rückerstattung mit klaren Begründungscodes.

Dispute-Center: Das „roundId“ -Bündel ↔ die Videoaufzeichnung (Timecode), damit der Support die Tickets schnell löst.

Leistung und Fehlertoleranz

Scaling: stateless-Adapter der Anbieter + Kafka/NATS als Event-Bus.

Speicher: heiß (Redis) für Sitzungen/Limits, warm (Postgres) für Ledger, kalt (S3) für Protokolle.

Folbacks: Wenn die Brieftasche nicht antwortet - „SOFT _ DECLINE“ mit Retrays; wenn der Anbieter nicht verfügbar ist - deaktivieren Sie die Tische/verstecken Sie sich in der Lobby.

Idempotente Retrays: Es ist sicher, 'placeBet '/' settle' auf Netzwerk-Timeouts zu wiederholen.

UX: Frontend-Muster

Uhrensynchronisation: Verwenden Sie' serverTime' von Bridge für Timer „Schließen von Wetten durch“....

Lokalisierung: Händlersprache ≠ Schnittstellensprache; Untertitel/Glossar der Begriffe anzeigen.

Stream-Player: Auto-Fallback WebRTC → LL-HLS bei schlechtem Netzwerk.

Fehler UI: verständliche Codes ('LBRG-401 TOKEN_EXPIRED',' LBRG-429 LIMIT_EXCEEDED', 'LBRG-503 PROVIDER_DOWN').

Multi-Tisch: Schneller Tischschwung ohne Session-Pause (reuse' sessionId').

Anti-Muster

Speichern Sie langlebige Token auf dem Client.

Akzeptieren Sie die Wette nach 'WettenGeschlossen' wegen der Dilay - der Streit ist garantiert.

Das Fehlen von 'idempotencyKey' → Double bei Retrays.

Mixen Sie Zeitzonen in 'roundId' und Reports.

Setzen Sie Grenzen „auf das Auge“ ohne Profile und KYC-Status.

Ignorieren Sie die QoS des Streams - hohe Churn auf mobilen Netzwerken.

Schritt-für-Schritt-Umsetzungsplan (Checkliste)

Architektur und Verträge

Einen einzigen Vertrag Ereignisse zu beheben: 'bet. place`, `bet. accepted`, `bet. rejected`, `round. settle`, `limits. update`, `session. close`, `provider. error`.
Idempotency und die Formate' roundId', 'betId', 'transactionId' definieren.
Wählen Sie ein Wallet-Modell (Seamless Priorität).

Sicherheit

mTLS zu den Anbietern, HMAC-Signatur-Webhooks, TTL-Token ≤ 10 Minuten.
RG/AML/KYT Politik vor der Zulassung zu Wetten, Audit-Log.

Katalog und Grenzen

Import von Tabellen und Limitprofilen, Mapping nach Land/Währung/CUS.
Hot Update der Tischlimits und -status.

Frontend

WebRTC-Player mit LL-HLS-Folback, Synchronisationsuhr, stabile Wetttimer.
Fehlercodes und menschliche Nachrichten.

Test-Plan

High-latency/packet-loss Szenarien, reconnection ohne Wettverlust.
Doppelklick auf den Einsatz → eine Belastung (Idempotenz).
VOID/REFUND, kontroverse Runden, Diskrepanzen der Berichte.

Beobachtungsstand

Дашборд QoS: RTT, dropped frames, aborted rounds, time-to-settle.
Alertas durch SLA-Anbieter, reconcile Berichte.

Bridge verwandelt den „Zoo“ der Live-Integrationen in ein überschaubares System: Flatrates, einheitliche Abrechnungen, vorhersehbare UX und transparente Qualitätskontrolle des Streams. Mit einer richtig gestalteten Brücke verbindet der Betreiber neue Live-Anbieter schneller, reduziert technologische Risiken und schützt P&L durch Idempotenz, strenge Grenzen und klare Beobachtbarkeit.