LiveG24 - Überblick und Integration

Ein kurzer Überblick

LiveG24 ist ein Live-Casino-Anbieter, der sich auf die klassischen Disziplinen (Roulette, Blackjack, Baccarat) und ihre beschleunigten/variablen Modi konzentriert. Der Schwerpunkt liegt auf stabilem Streaming mit geringer Latenz, flexibler Lokalisierung (Sprachen/Währungen) und vorhersehbarer Server-to-Server-Integration in die Wallet des Betreibers. Techstack kombiniert WebRTC (für Echtzeit) mit Fallback auf HLS/DASH sowie Web-Sockets für Wetten und Ergebnisse.

Für wen geeignet: mittlere und große Betreiber/Aggregatoren, denen eine schnelle Anbindung der Live-Verticals, transparente Wallet Collbacks, flexible Limits und Telemetrie wichtig sind.

Portfolio und User Experience

Spiele und Variationen

Roulette: Europäisches/Auto-Roulette, beschleunigte Modi, Hot/Cold-Statistiken, schnelle Wettwiederholungen.
Blackjack: Classic, Speed-Tische, Bet Behind, Nebenwetten und Tischversicherung.
Baccarat: Klassiker, Keine Kommission/Geschwindigkeit, „Roadmaps“, zusätzliche Wettpools.

UX/UI

HTML5-Client mit adaptivem Layout, Chip-Presets, schnelle Re-Wetten.
Geschichte der Hände/Spins, Chat mit Moderation, Hinweise auf Grenzen und Verantwortung.
Mehrsprachigkeit, Mehrwährungen, lokale Zahlen-/Datumsformate.

Verantwortungsvolles Spielen

Wett-/Zeitlimits, Tisch-Hidden nach Geo/Alter, RG-Nachrichten nach Gerichtsbarkeit.

Threads, Protokolle und Performance

Video: WebRTC für niedrige Latenz (~ 0. 5–2. 5 s bei stabilem Netzwerk), Fallback auf HLS/DASH bei Degradation.
Lieferung: CDN/Edge-PoP, Sticky-Routing zum nächstgelegenen Knoten, Health-Checks Nod, schneller Failover.
ABR: adaptive Bitrate, nahtlose Schaltungen; auf mobile - Hardware-Decodierung.
Netzwerkhygiene: Latenz bis Kante <150-200 ms, HTTP/2 +, TLS 1. 2 +, Priorität des Multimedia-Verkehrs.

Mathematik, Grenzen und Berechnungen

RTP/House Edge: entsprechen den Regeln und Nebenwetten eines bestimmten Tisches (in den Regeln offenbart).
Limits: global (pro Tisch) und persönlich (pro Spieler); VIP-Level; separate Obergrenzen für Nebenwetten.
Währungen: Berechnung in Minor-Einheiten; Konvertierung/Anzeige - auf der Bedienerseite; korrekte Rundungen nach dem Recht der Gerichtsbarkeit.
Commerce: RevShare/Flat/Hybrid ist vertraglich festgelegt und hat keinen Einfluss auf die Kundenmathematik.

Integrationsmodell

Schema auf hoher Ebene

1. Spieler → Frontend-Betreiber → SSO/JWT

2. Operator/Aggregator API ↔ LiveG24 API - Erstellung und Validierung von Sitzungen

3. Client ↔ WebRTC/HLS - Videostream

4. Client ↔ WebSocket - Gebote/Ereignisse (geringe Latenz)

5. LiveG24 → Webhook/Callback - Autorisierung von Abbuchungen/Auszahlungen

6. Auth Debit/Credit ↔ Ledger/KYC/AML

7. BI/Anti-Fraud/Monitoring - Audit, Retrays, Reconciliation

Anforderungen an die Umgebung

Sicherheit: JWT/OAuth2 für Sitzungen, allowlist IP/Mutual-TLS für S2S, kurze TTL-Token, Schlüsselrotation.
Leistung: Auto-Skalierung von WS-Shards, Balancing mit Sticky-Sessions.
Kompatibilität: aktuelle Chrome/Edge/Safari/Firefox, iOS/Android WebView.

Sitzungen, Start und Authentifizierung

SSO-Muster

Der Operator bildet ein kurzlebiges Token mit 'player _ id', Währung, Lokalität, VIP/Limits und 'return _ url'. Der Provider gibt 'launch _ url' zurück.

Beispiel S2S (Pseudo-REST):


POST /api/v1/sessions
Authorization: Bearer <operator-key>
{
"player_id": "u_284710",
"currency": "EUR",
"locale": "ru-RU",
"limits": { "table_min": 1.00, "table_max": 10000.00, "side_bet_max": 200.00 },
"meta": { "vip_level": 2, "return_url": "https://op.example.com/return" }
}

Die Antwort lautet:


{
"session_id": "sess_9d3f...",
"launch_url": "https://liveg24.example/launch?sess=sess_9d3f...",
"expires_in": 3600
}

Client starten

Durch 'launch _ url' im iFrame/neuem Fenster (CSP/' X-Frame-Options' stimmen überein). Heartbeat/refresh verlängert die Sitzung.

Wetten und Veranstaltungen (WebSocket)

Arten von Ereignissen

Игровые: `ROUND_OPEN`, `BETS_OPEN`, `BETS_CLOSED`, `ROUND_RESULT`

Transaktional: „BET _ PLACED“, „BET _ ACCEPTED/REJECTED“, „PAYOUT“

Dienstprogramm: „PING/PONG“, „RECONNECT _ HINT“, „ERROR“

Beispiel für das Ergebnis der Runde:


{
"type": "ROUND_RESULT",
"table_id": "roulette_eu_05",
"round_id": "r_2025_11_02_15_42_17",
"result": { "number": 8, "color": "black" },
"payouts": [
{ "bet_id": "b_9182", "amount_minor": 360000 },
{ "bet_id": "b_9183", "amount_minor": 0 }
],
"server_ts": "2025-11-02T13:42:19Z"
}

Zuverlässigkeit des Kanals

Auto-reconnect, Wiederherstellung von Abonnements und Status der aktuellen Runde.
Back-pressure: Begrenzung der Häufigkeit von Client-Nachrichten.
Deduplizierung durch 'bet _ id '/' round _ id' auf Anbieter- und Betreiberseite.

Geldtransaktionen und Wallet Collbacks

Ströme

Auth-Debit (Rate): Antrag auf Abbuchung/Einfrieren, Antwort des Operators' APPROVED/DECLINED'.
Kredit (Auszahlung): wird vom Anbieter initiiert, der Betreiber bestätigt und gibt den Restbetrag zurück.
Reconciliation: Periodische Runden-/Transaktionsberichte zur Abstimmung mit dem Ledger.

Versandgarantien

Idempotenz durch 'X-Idempotency-Key' (TTL ≥ 24 h), Nummerierung von Nachrichten pro Spieler.
Retrays mit exponentieller Pause, Kontrolle der Verarbeitungsreihenfolge.

Beispiel für eine Kollegenzahlung:


POST /wallet/payouts
Idempotency-Key: 7c1a-...
{
"player_id": "u_284710",
"round_id": "r_2025_11_02_15_42_17",
"bet_id": "b_9182",
"amount_minor": 360000,
"currency": "EUR"
}

Lobby-Einstellungen und Promo

Tischkatalog: Gruppierung nach Disziplintyp, Händlersprache, Limits, VIP-Levels.
Promo-Widgets: Banner, Turniere, Missionen/Quests, „heiße Zahlen“, Top-Gewinne.
Geo-Filter: Whitelist/Blacklist von Jurisdiktionen, lokale Anforderungen von Responsible Gaming.
UI-Parameter: Auto-Login an einem bestimmten Tisch, Ausblenden des Chats, Voreinstellungen für Wetten, benutzerdefinierte Bezeichnungen.

Skalierung und Fehlertoleranz

Multi-Region: Auswahl des nächstgelegenen RoR/Studios, ASN/Geo-Routing.
Balancing: Sticky nach Spieler/Tisch; bei Störungen - transparentes Re-Join.
Quoten/Ratenlimits: WS-Abonnement-/Gebotsänderungslimits, Schutz vor Sturmereignissen.
Degradation: Fallback auf HLS, „lite-UI“ für schwache Geräte oder schlechtes Netzwerk.

Sicherheit und Compliance

Verschlüsselung: TLS 1. 2+, HSTS; SRTP für WebRTC.
Zugang: JWT mit kurzer TTL, IP allowlist/Mutual-TLS für Collecks, Signatur von Anfragen.
PII-Minimierung: Maskierung von Identifikatoren; Logs ohne offene PIIs.
Anti-Betrug: Verhaltenssignale (Wetthäufigkeit, multiple Sessions, VPN/ASN-Muster), Risikoflags und Trottling.
RG/Regulatory: Selbstausschluss/Timeouts/Limits, lokale Banner und Cookie-Einwilligungen.

Monitoring, Reporting und SLA

Metriken

Aptime: media/WS, p50/p95 delays,% frame-drops, collecquecs error (shares/codes).
Produkt: 'Launch → First Bet' Conversion, mittlerer Check, Beibehaltung nach Disziplinen/Sprachen, ROI Promo.
Transaktionen: Retrays und ihre Ursachen, der Anteil der vom Wallet abgelehnten Berechtigungen.

SLO/SLA (Benchmarks)

Medien ≥ 99. 9%, API ≥ 99. 95% Aptame.
Kollbeki: p95 <500 ms innerhalb der Region.
Reconnect WS: p95 <3-5 s, Wiederherstellung von Abonnements - automatisch.

Dashboards/Alerts

Korrelation 'round _ id/bet _ id/callback _ id', Incident Traces, Status Panel mit Kommunikationsregeln.

Prüfung und Abnahme

1. Sandbox: einzelne Schlüssel, fiktive Runden/Limits Ergebnisse.
2. E2E: erfolgreiche/abgelehnte Wetten, WS-Klippen, doppelte Auszahlungen (Idempotenzprüfung), Grenzkonflikt.
3. Belastung: Primetime/Turnierspitzen, ABR-Schaltung, Degradierung zur HLS.
4. Sicherheit: JWT Negativfälle, Signatur Kollebacks, Rate-Limits, CORS/CSRF-Politik.
5. Reconciliation: Abstimmung der Berichte des Anbieters mit dem Ledger (Summen, Status, Rundungen).

Best Practices für die Integration

Machen Sie das Portemonnaie des Betreibers zur Quelle der Wahrheit; Alle S2S sind idempotent.
Teilen Sie die Kollbecks in Warteschlangen ('bets', 'payouts', 'recon') mit Prioritäten/Retrays.
Caching Tischlimits/Configs am Rand (TTL + manuelle Behinderung).
Verwenden Sie Feature-Flags, um Tische/Sprachen/VIP-Limits schrittweise zu öffnen.
Planen Sie Fail-Over: Fallback-Protokolle, „technische Pause“, Kompensations-Promo.
Protokollieren Sie PII-Hashes und Korrelationsschlüssel anstelle von direkten IDs.

Schecks-Blätter

Für die Entwicklung

JWT/SSO Generierung/Validierung
WebRTC + fallback HLS Client
WS-Client mit Auto-Reconnect und Back-Pressure
Idempotente S2S-Endpunkte, Retrays, Deduplizierung
PII Masking, Schlüssel/Geheimnisse Rotation

Zum Starten

Sprachen/Währungen/Formate (L10n)
Geo-Filter und Jurisdiktionsbeschränkungen
SLO-Überwachung (API/Stream/WS) + Warnungen
Nachtberichte und Reconciliation
Incident Plan und Status-Seiten

FAQ (kurz)

Kann ich in iFrame starten? Ja, über 'launch _ url' unter den vereinbarten CSP/' X-Frame-Options'.
Gibt es Speed/Bet Behind? Verfügbar auf einer Reihe von Tabellen nach Konfiguration.
Wie gehe ich mit Kommunikationsabbrüchen um? Auto-reconnect, Wiederherstellung von Abonnements/Wetten, idempotente Kollbecks.
Gibt es Promo-Tools? Banner, Turniere, Missionen/Quests, Veranstaltungen für die Analytik.
Wie funktioniert die Reconciliation? Der Anbieter veröffentlicht Berichte; Der Operator prüft mit dem Ledger nach 'round _ id/bet _ id'.

Ergebnis

LiveG24 ist ein praktischer Live-Anbieter mit modernem Streaming und einem vorhersehbaren Integrationsmodell. Die Einhaltung der beschriebenen Muster (SSO, WebRTC + WS, Wallet mit idempotenten Collecks, SLO-Monitoring, RG/Compliance) gewährleistet einen nachhaltigen Betrieb zu Stoßzeiten, eine korrekte Wirtschaftlichkeit der Live-Vertical und eine Minimierung der operativen Risiken.