LiveG24 - Overview and Integration

Summary

LiveG24 is a Live casino provider focused on classic disciplines (roulette, blackjack, baccarat) and their accelerated/variable modes. The key focus is stable streaming with low latency, flexible localization (languages/currencies) and predictable server-to-server integration with the operator's wallet. Techstack combines WebRTC (for real-time) with fallback on HLS/DASH, as well as web sockets for bets and results.

Who fits: medium and large operators/aggregators who care about fast Live vertical connection, transparent wallet collars, flexible limits and telemetry.

Portfolio and user experience

Games and variations

Roulette: European/auto roulette, accelerated modes, hot/cold stats, quick bet repeats.
Blackjack: Classic, Speed Tables, Bet Behind, Side Bets and Table Rule Insurance.
Baccarat: Classic, No Commission/Speed, Roadmaps, extra betting pools.

UX/UI

HTML5 client with adaptive layout, chip presets, fast re-bets.
History of distributions/spins, chat with moderation, hints on limits and responsibilities.
Multilingualism, multicurrency, local number/date formats.

Responsible play

Rate/time limits, hiding geo/age tables, RG messages according to jurisdiction.

Threads, Protocols, and Performance

Video: WebRTC for low latency (~ 0. 5–2. 5 s at stable network), HLS/DASH fallback at degradation.
Delivery: CDN/edge-PoP, sticky routing to the nearest node, health-checks nodes, fast failover.
ABR: adaptive bitrate, seamless switching; on mobile - hardware decoding.
Network hygiene: latency up to edge <150-200 ms, HTTP/2 +, TLS 1. 2 +, multimedia traffic priority.

Mathematics, limits and calculations

RTP/House Edge: comply with the rules and side rates of a specific table (disclosed in the rules).
Limits: global (by table) and personal (by player); VIP levels; separate ceilings for side bets.
Currencies: calculation in minor-units; conversion/display - on the operator side; correct rounding by jurisdiction.
Commerce: RevShare/Flat/Hybrid is defined by contract and does not affect client math.

Integration model

High-level diagram

1. Player → Frontend Operator → SSO/JWT

2. Operator/Aggregator API ↔ LiveG24 API - Session Creation and Validation

3. ↔ WebRTC/HLS Client - Video Stream

4. ↔ WebSocket Client - Bets/Events (Low Latency)

5. LiveG24 → Webhook/Callback - authorization of write-offs/payments

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

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

Environmental requirements

Security: JWT/OAuth2 for sessions, allowlist IP/Mutual-TLS for S2S, short TTL tokens, key rotation.
Performance: auto-scaling WS-shards, balancing with sticky-sessions.
Compatibility: current Chrome/Edge/Safari/Firefox, iOS/Android WebView.

Sessions, Startup, and Authentication

SSO pattern

The operator generates a short-lived token with 'player _ id', currency, locale, VIP/limits and 'return _ url'. The provider returns' launch _ url '.

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

Answer:


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

Starting the client

Via 'launch _ url' in iFrame/new window (CSP/' X-Frame-Options' agree). Heartbeat/refresh extends session.

Bets and Events (WebSocket)

Event types

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

Transactional: 'BET _ PLACED', 'BET _ ACCEPTED/REJECTED', 'PAYOUT'

Service: 'PING/PONG', 'RECONNECT _ HINT', 'ERROR'

Sample round result:


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

Channel reliability

Auto-reconnect, restore subscriptions and current round status.
Back-pressure: limiting the frequency of client messages.
Deduplication by 'bet _ id '/' round _ id' on the provider and operator sides.

Purse cash transactions and collecks

Streams

Auth-debit (rate): request for write-off/freezing, operator's response'APPROVED/DECLINED '.
Credit (payout): initiated by the provider, the operator confirms and returns the balance.
Reconciliation: periodic reports on rounds/transactions for reconciliation with the ledger.

Delivery guarantees

Idempotency via 'X-Idempotency-Key' (TTL ≥ 24 h), message numbering per player.
Retrai with exponential pause, processing order control.

Example of a payment collbeck:


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 settings and promo

Table catalog: grouping by discipline type, dealer language, limits, VIP levels.
Promo widgets: banners, tournaments, missions/quests, hot numbers, top wins.
Geo-filters: whitelist/blacklist jurisdictions, local Responsible Gaming requirements.
UI-parameters: auto-entrance to a specific table, hiding chat, betting presets, custom denominations.

Scalability and fault tolerance

Multi-region: choosing the nearest RoR/studio, ASN/geo-routing.
Balancing: sticky by player/table; in case of failures - transparent re-join.
Quotas/Rate limits: limits of WS subscriptions/rate changes, protection against event storms.
Degradation: fallback on HLS, "lite-UI" for weak devices or bad network.

Safety and compliance

Encryption: TLS 1. 2+, HSTS; SRTP for WebRTC.
Access: JWT with short TTL, IP allowlist/Mutual-TLS for collbecks, request signature.
PII minimization: masking identifiers; logs without open PIIs.
Anti-fraud: behavioral signals (betting frequency, multiple sessions, VPN/ASN patterns), risk flags and throttling.
RG/Regulatory: self-exclusion/timeouts/limits, local banners and cookies.

Monitoring, reporting and SLAs

Metrics

Aptime: media/WS, p50/p95 latency,% frame-drops, collback errors (shares/codes).
Product: 'Launch → First Bet' conversion, average check, discipline/language retention, ROI promo.
Operations: retrays and their causes, the share of authorizations rejected by the wallet.

SLO/SLA (landmarks)

Media ≥ 99. 9%, API ≥ 99. 95% uptime.
Collbecks: p95 <500 ms within the region.
Reconnect WS: p95 <3-5 s, restore subscriptions automatically.

Dashboards/alerts

Correlation'round _ id/bet _ id/callback _ id ', incident traces, status panel with communication regulations.

Testing and acceptance

1. Sandbox: individual keys, fictitious round/limit outcomes.
2. E2E: successful/rejected bets, WS breaks, double payments (idempotency check), limit conflict.
3. Load: Prime time/tournament peaks, ABR switching, degradation to HLS.
4. Security: negative JWT cases, signature of collbecks, rate-limits, CORS/CSRF policies.
5. Reconciliation: reconciliation of provider reports with the ledger (amounts, statuses, rounding).

Integration best practices

Make the operator's wallet a source of truth; all S2S are idempotent.
Separate collabs in queues ('bets', 'payouts', 'recon') with priorities/retreats.
Cache limits/table configs on edge (TTL + manual disability).
Use feature-flags to open tables/languages/VIP limits in stages.
Plan fail-over: fallback protocols, "technical pause," compensation promos.
Log PII hashes and correlation keys instead of direct identifiers.

Check sheets

For development

JWT/SSO Generation/Validation
WebRTC + fallback HLS Client
WS client with auto-reconnect and back-pressure
Idempotent S2S endpoints, retrays, deduplication
PII masking, key/secret rotation

To start

Languages/Currencies/Formats (L10n)
Geo-Filters and Jurisdictional Constraints
SLO Monitoring (API/Stream/WS) + Alerts
Nightly Reporting and Reconciliation
Incident Plan and Status Pages

FAQ (Brief)

Can iFrame run? Yes, through 'launch _ url' with consistent CSP/' X-Frame-Options'.
Is there a Speed/Bet Behind? Available on a number of tables by configuration.
How to handle communication breaks? Auto-reconnect, restore subscriptions/rates, idempotent collbacks.
Any promotional tools? Banners, tournaments, missions/quests, analytics events.
How does reconciliation work? The provider publishes reports; the operator checks with the ledger by'round _ id/bet _ id '.

Result

LiveG24 is a practical Live provider with modern streaming and a predictable integration model. Compliance with the described patterns (SSO, WebRTC + WS, wallet with idempotent collabs, SLO monitoring, RG/compliance) ensures stable peak hours, correct Live vertical economics and minimization of operational risks.