So funktioniert die API für die Verbindung von Live-Spielen mit der Plattform

1) Allgemeine Architektur und Komponentenrollen

Betreiberplattform (Casino-Plattform): Konten, Wallet, Bonus-Engine, Limits, KYC/AML, Transaktionslog.

Anbieter von Live-Spielen (Studio/Provider): Studios, Händler, Videostreams (WebRTC/Low-Latency HLS), Spieleserver Runden.

Aggregator (manchmal): eine einzige API zu Dutzenden von Anbietern, Vereinheitlichung von Währungen/Limits/Ereignissen.

Kunden-Frontend: Web/Mobile-Client mit UI-Wetten, Videoplayer, Chat, lokale Tipps.

Unterstützende Dienste: Risiko/Anti-Betrug, Protokollierung, Analyse, Message Queuing (Kafka/RabbitMQ), Überwachung.

Die typisierte Topologie: der Kunde → (JWT) → der Bahnsteig → (server-to-server) → der Provider, parallel der Kunde bekommt den Videostrom vom CDN/Pool der Medienserver.

2) Der Lebenszyklus des Spielers und der Session

2. 1. Login und „Spiel-Token“

1. Der Spieler meldet sich auf der Plattform an.

2. Die Plattform ruft CreateGameSession beim Anbieter (S2S) auf, übermittelt 'player _ id', 'currency', 'country', 'bet _ limits', Flaggen des verantwortlichen Spiels.

3. Der Anbieter gibt Einweg- game_token und launch_url zurück.

4. Der Client öffnet 'launch _ url' im iframe/new tab, indem er 'game _ token' hinzufügt (oder erhält 302 auf der End-URL des Spiels).

Beispiel für eine S2S-Abfrage:

http
POST /api/v1/sessions
Content-Type: application/json
Authorization: Bearer <platform_api_key>

{
"player_id": "u-918273",  "session_id": "sess-5f3b2",  "currency": "EUR",  "country": "DE",  "lang": "de",  "bet_limits": {"min": 0. 5, "max": 2000},  "responsible_gaming": {"self_excluded": false, "deposit_limit_left": 150},  "callback_urls": {
"balance": "https://platform. example. com/wallet/balance",   "debit":  "https://platform. example. com/wallet/debit",   "credit": "https://platform. example. com/wallet/credit",   "rollback":"https://platform. example. com/wallet/rollback",   "events": "https://platform. example. com/game/events"
}
}

Antwort des Anbieters:

json
{
"game_token": "gtkn_7f0...e2a",  "launch_url": "https://live. provider. com/launch/roulette",  "expires_in": 900
}

2. 2. Authentifizierung an der Front

Das Spiel wird geladen, validiert 'game _ token' durch sein Beckend.

WebSocket wird auf dem Spielserver für Wetten/Events installiert.

Der Videostream läuft über WebRTC (low latency 0. 5-2 s) oder LL-HLS (2-5 s).

3) Geld und Wetten: Wallet API und Idempotenz

3. 1. Saldo und Belastung/Gutschrift

Der Anbieter speichert nicht das „Geld“ des Spielers - er ruft die Platform Wallet API auf:

`GET /wallet/balance? player_id' → aktuell verfügbar.
„POST/wallet/debit“ → den Einsatz abschreiben.
„POST/Wallet/Credit“ → den Gewinn/die Rendite gutschreiben.
„POST/Wallet/Rollback“ → ein Rollback der Transaktion, wenn die Runde abgebrochen wird.

Wichtig: Alle Geldtransaktionen sind idempotent durch 'transaction _ id '/' round _ id'. Das Wiederholen derselben Abfrage ändert nichts am Ergebnis.

Beispiel einer Belastung (Rate):

http
POST /wallet/debit
Idempotency-Key: trx-7a2df-001
Content-Type: application/json

{
"player_id": "u-918273",  "round_id": "r-2025-10-18-12:30:15Z-001",  "transaction_id": "trx-7a2df-001",  "amount": 25. 00,  "currency": "EUR",  "bet_type": "roulette_straight",  "meta": {"table_id":"ru-11", "selection":"17", "odds":35}
}

3. 2. Timings und Wettstatus

WINDOW_OPEN → WINDOW_CLOSING → WINDOW_CLOSED. Nach 'WINDOW _ CLOSED' verbietet der Provider neue Belastungen.

Späte Wetten werden mit dem Code' LATE _ BET 'abgelehnt.

Wenn die Verbindung unterbrochen wird, kann der Client die Wette erneut senden - der Server muss in der Lage sein, das Duplikat nach Idempotency-Key zu unterscheiden.

Transaktionsstatus: „PENDING“, „SETTLED“, „ROLLED _ BACK“, „REJECTED“.

4) Veranstaltungen der Runde: Modell und Reihenfolge

4. 1. Ereignisdiagramm von WebSocket

`round. started '→ kommt' round _ id', der Wetttimer.

`bet. akzeptiert/rejected '→ Bestätigung für jede Wette.

`round. closed '→ Wetten werden nicht mehr akzeptiert.

`round. Ergebnis' → Ergebnis (Sektor Roulette/Karten/Würfel).

`payout. created '→ der Gewinnbetrag pro Spieler.

`round. settled '→ Endstatus, Prüfsumme.

Beispiel für ein Ergebnisereignis:

json
{
"type": "round. result",  "round_id": "r-2025-10-18-12:30:15Z-001",  "table_id": "ru-11",  "payload": {
"roulette": {"number":17, "color":"black"},   "hash": "sha256:8a7b...d1c",   "video_ts": "2025-10-18T12:30:23. 450Z"
}
}

4. 2. Konsistenz und Prüfsummen

Jedes Ereignis wird mit 'seq' und 'signature' (mTLS + request body signature) versehen.

Bei der Reconciliation wird 'payout _ checksum' angegeben - die Summe aller Credits nach 'round _ id' muss konvergieren.

5) Videostream und Verzögerung

WebRTC für Live-Hand-Wetten (Blackjack/Baccarat/Roulette) - striktes Verzögerungsbudget <2 c zum Kunden.

LL-HLS/DASH für Zuschauer/Maßstab, erlaubt 2-5 c.

Zeitsynchronisation: NTP/chrony, in payload - 'video _ ts' für Replays und Kontroversen.

Folback: Bei der Degradation von WebRTC → der automatische Wechsel zu LL-HLS mit der Blockierung von späten Wetten.

6) Fehler, Retrays, Timeouts

Allgemeine Regeln:

Alle S2S-Anrufe mit einem Timeout von 800-1500 ms, Retrays mit exponentieller Pause und Jitter, aber ohne erneutes Abschreiben des Geldes (Idempotenz).

Wallet-Fehlercodes:

`INSUFFICIENT_FUNDS`, `LIMIT_EXCEEDED`, `ACCOUNT_LOCKED`, `DUPLICATE_TRANSACTION`, `LATE_BET`, `CURRENCY_MISMATCH`.

Fehlerformat:

json
{
"error": "INSUFFICIENT_FUNDS",  "message": "Balance 18. 00 < required 25. 00",  "transaction_id": "trx-7a2df-001"
}

7) Boni, Freispiele, Versicherungen

Parallel zur „Geld“ -Geldbörse kann es ein Bonusguthaben geben: payload zeigt die Quelle der Abbuchung an 'source: CASH	BONUS`.
Bei Live-Spielen sind Versicherungen/Side Bets (z.B. beim Blackjack) keine Seltenheit - es handelt sich um einzelne Transaktionen mit eigenen Limits und Quoten.
Rundungsregeln: Bank (half-to-even) oder zugunsten des Spielers/Betreibers - muss im Integrationskonfig festgehalten werden.

8) Verantwortungsvolles Spielen und Einschränkungen

Sitzungsflags: 'self _ excluded', 'cooldown _ until',' loss _ limit _ left', 'time _ limit _ left'.

Der Anbieter kann vor jeder Abbuchung "validate _ limits' anfordern.

Die Plattform kann force_close_session auslösen: Der Spieler ist ausgeschlossen/hat das Limit überschritten → der Anbieter schließt das Wettfenster und macht Rückgaben für nicht gespielte Wetten.

9) Sicherheit und Compliance

mTLS für S2S, HSTS, strenge IP-allowlist.

JWT/JWS mit kurzer TTL für Front-End-Token, Audience/Issuer-Prüfung.

Signatur des Webhooks des Anbieters (HMAC-SHA256 über dem Körper).

Händleraktionsprotokolle, Rundenreplikationen, unveränderliches Audit (WORM-Speicher).

Speicherung personenbezogener Daten - PII-Minimierung, Tokenisierung von 'player _ id', Aufbewahrungsfristen nach Gerichtsbarkeit (DSGVO und Analoga).

Geo-Sperren und Verbote nach Jurisdiktionen auf CreateGameSession-Ebene.

10) Reconciliation und Finanzen

10. 1. Stunden-/Tagesberichte

Der Anbieter meldet „round _ id → total_bets, total_wins, fees“. Die Plattform fasst zusammen:

Lastschriftbetrag = Σ Einsätze, Kreditbetrag = Σ Gewinne + Rückgaben, Delta = GGR (einschließlich Boni/Jackpots/Provisionen).

Berichtsformat:

json
{
"date": "2025-10-18",  "currency": "EUR",  "tables": [{
"table_id": "ru-11",   "rounds": 1260,   "total_bets": "45230. 00",   "total_payouts": "43012. 50",   "jackpot_contrib": "302. 00",   "provider_fee": "2. 5%"
}]
}

10. 2. Rollback-Drehbucher

Video-/Storyboard-Fehler → rund. storniert: Der Anbieter sendet einen „Rollback“ an alle Wetten in der Runde.

Doppelte Lastschriftverarbeitung, die auf der Plattform → 'DUPLICATE _ TRANSACTION' und 200 OK mit dem vorherigen Ergebnis gefangen wurde.

11) Chat, Moderation und UI-Veranstaltungen

Die Chat-Ereignisse laufen über einen separaten Kanal (WebSocket # 2) mit Stoppwortfiltern.

Systemankündigungen (close bets, winner list) - nur aus vertrauenswürdiger Quelle des Anbieters, signiert/zeitgestempelt.

12) Prüfung und Zertifizierung

Sandbox-Anbieter: feste Ergebnisse, die Fähigkeit, die' Runde zu erzwingen. result`.

QS-Schaltung: Testtisch mit abgespeckten Wettfenstern (5-8 c) und beschleunigtem Flow.

Last: Simulation von 5-10 Tausend gleichzeitigen Spielern, Spitzenbelastungen pro Sekunde (TPS) ≥ geplante × 1. 5.

Integrationszertifizierung: Checklisten zu Idempotenz, Währungen, Rundung, Umgang mit Ausfällen, Einhaltung von Limits und Selbstausschluss.

13) Metriken und SLOs

Tets: median/95p Latenz für 'debit/credit', WebSocket round-trip, Zeitsynchronisationsfehler, drop-rate WebRTC.

Продукт: bet acceptance rate, late-bet rate, dispute rate, chargeback rate, session duration, retention, ARPU/LTV.

SLO Beispiele:

99. 5% `debit` ≤ 1. 2 s, 99. 9% Lieferung 'rund. Ergebnis' ≤ 300 ms nach der Fixierung, Video-Verzögerung ≤ 2. 5 s für 95p WebRTC.

14) Mehrwährungen, Steuern, Lokalisierung

Die Umrechnung erfolgt außerhalb des Anbieters: Das Spiel läuft ausschließlich in der Währung der Session.

Steuern/Einbehaltungen sind auf der Seite der Plattform bei 'credit' (Feld 'withholding').

Lokalisierung: 'lang', Zahlen-/Währungsformat, Zeitzone für Timer und Berichte.

15) Integrationsmöglichkeiten

1. Direct-to-Provider: maximale Kontrolle und Kontrolle, aber separate Verträge/Zertifizierungen.

2. Durch den Aggregator: schnelle Abdeckung durch Anbieter, einheitliche Systeme, manchmal weniger Flexibilität.

3. Hybrid: Top-Tische direkt, der Rest über den Aggregator.

16) Mini-Spezifikation (gesamt)

16. 1. WebSocket Inbound (vom Kunden zum Anbieter)

json
{ "type":"bet. place", "bet":{
"amount": 25, "selection":"17", "table_id":"ru-11"
}, "idempotency_key":"c3a2-...-001" }

16. 2. WebSocket ausgehend (vom Anbieter zum Kunden)

json
{ "type":"bet. accepted", "bet_id":"b-8821", "seq":12031 }
{ "type":"round. closed", "round_id":"r-...001", "seq":12050 }
{ "type":"round. result", "result":{"number":17,"color":"black"}, "seq":12070 }
{ "type":"payout. created", "amount":875, "currency":"EUR", "seq":12075 }

16. 3. Wallet S2S (Plattform ↔ Anbieter)

„POST/wallet/debit“ (idempotent)

„POST/wallet/credit“ (idempotent)
„POST/wallet/rollback“ (idempotent)

Unterschrift HMAC, 'Timestamp', 'Nonce', Wiederholungsschutz (TTL ≤ 60 c).

17) Kantenkoffer und wie man sie schließt

Verbindungsabbruch beim Spieler: Wette gesendet, keine Bestätigung → Wiederholung mit dem gleichen 'Idempotency-Key'; Der Server antwortet mit dem vorherigen Status.

Händler-/Deckwechsel in der Runde: automatische Stornierung und voller 'Rollback'.

Währungsabweichung: 'CURRENCY _ MISMATCH' + Ereignisprotokoll; Das Spiel wird gesperrt, bis die Sitzung erneut freigegeben wird.

Selbstausschluss zum Zeitpunkt des Spiels: sofortige' force _ close _ session', Rückgabe von ungespielten.

Änderung der Videoqualität: nur Client, keine Auswirkungen auf Timer/Wetten.

WebSocket Re-Handshake: ohne Verlust der Ordnung - Event-Warteschlange mit 'seq', „Aufholjagd“ verpasst.

18) Checkliste Produktionsstart

Sicherheit

mTLS + pinning Zertifikat, IP-allowlist.
Signatur aller Webhooks und Verifizierung von 'Timestamp '/' Nonce'.
Mini-PII: nur 'player _ id' (tokenisiert).

Zuverlässigkeit

Idempotenz aller Geldtransaktionen.
Wiederholungen der Runden und unveränderliches Audit.
WebRTC → LL-HLS Auto-Folback.

Produkt

Limits/Responsible Play werden in Echtzeit angewendet.
Native Hinweise zum Zeitpunkt der Wette.
SLO Dashboards + Alerts 24/7.

Die API für die Integration von Live-Spielen ist ein Bündel von Low-Serve-Streams, Ereignisbussen und idempotenten Wallets mit strengen Anforderungen an Nachrichtenreihenfolge, Timings und Sicherheit. Die erfolgreiche Umsetzung setzt auf: einen strengen Lebenszyklus von Wetten und Runden, überprüfbare Konsistenz (Reconciliation), Datenschutz und die Grenzen des verantwortungsvollen Spielens - und macht aus einer „schönen Sendung“ ein zuverlässiges, zertifizierbares Finanzprodukt.