OnAir Entertainment - Overview and Integration

Overview

OnAir Entertainment is a studio live casino provider with an emphasis on quality video production, multi-camera angles and fast connection to operator/aggregator platforms. The portfolio covers the main Live disciplines: roulette, blackjack, baccarat and their "high-speed "/auto options, as well as live show formats. The tech stack focuses on low broadcast latency (WebRTC) with fallback on HLS/DASH, geo-distributed delivery, and a stable backend for live bets/payouts.

Who is suitable: medium and large operators who care about flexible limit settings, localization, transparent wallet collars and detailed telemetry by table.

Portfolio and user experience

Main products

Roulette: European/American, auto roulette, Speed /Lightning pace, statistics tracks (hot/cold), quick repetitions of bets.
Blackjack: Classic and Speed tables, Bet Behind, insurance/side rates according to the rules of the table.
Baccarat: classic, No Commission, Speed modes, Roadmaps.
Live shows/specials: fast television formats and themed tables.

UX/UI

Adaptive HTML5 client, minimalistic UI, fast chips and betting presets.
Spin/giveaway history, moderated chats, limit notifications.
Multilingual interface, localization of date/separator formats, multi-currency support.

Responsible play

Support for rate/time restrictions, hiding tables by geo/age (operator flags), displaying Responsible Gaming policies.

Streaming technology and performance

Protocols: WebRTC (low latency ~ 0. 5–2. 5 s with stable network); HLS/DASH degradation fallback.
CDN/Edge: PoP distribution, health-checks nodes, sticky-routing to the nearest node.
ABR: adaptive bitrate, seamless quality switching without breakage.
Mobile clients: hardware decoding, power optimization, resistance to background switches.

Network Recommendations

Latency up to edge <150-200ms for comfortable UX.
HTTP/2+, TLS 1. 2 +, TCP BBR (if possible), multimedia traffic prioritization.

Math, limits and calculations

RTP/House Edge: comply with the rules of specific tables and side rates (disclosed in the rules of the table).
Limits: min/max by table and/or player, VIP levels, separate ceilings for side betting.
Currencies: internal unit in minor-units; conversion and display - on the operator's side; correct rounding by jurisdiction.
Commerce models: RevShare/Flat/Hybrid - at the contract level, fiscally "outside" client mathematics.

Integration model

High-level diagram

1. Player → Frontend Operator → SSO/JWT

2. Operator/Aggregator API ↔ OnAir API: session creation/validation

3. WebRTC/HLS ↔ Client Video Stream

4. ↔ WebSocket Customer Live Betting/Events

5. OnAir → Webhook/Callback to operator: authorization of charges/payments

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

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

Environmental requirements

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

Sessions, startup and authentication

SSO pattern

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

Example (pseudo-REST, S2S):


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

Answer:


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

iFrame/Window Open

Launch via 'launch _ url' (with CSP, 'X-Frame-Options' agreed in advance). Hartbit/refresh extends the session.

Bets and Events (WebSocket)

Event types

Потоковые: `TABLE_STATE`, `ROUND_OPEN`, `BETS_OPEN`, `BETS_CLOSED`, `ROUND_RESULT`

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

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

Example result:


{
"type": "ROUND_RESULT",
"table_id": "roulette_eu_07",
"round_id": "r_2025_11_02_15_23_05",
"result": { "number": 21, "color": "red" },
"payouts": [
{ "bet_id": "b_1001", "amount_minor": 360000 },
{ "bet_id": "b_1002", "amount_minor": 0 }
],
"server_ts": "2025-11-02T13:23:07Z"
}

Channel reliability

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

Purse money transactions and collbacks

Streams

Auth-debit (rate): the provider requests a write-off/freeze; operator responds'APPROVED/DECLINED '.
Credit: the provider initiates the credit; the operator confirms the status and returns the balance.
Reconciliation: periodic reports on rounds/transactions.

Delivery Guarantees

Idempotency via 'X-Idempotency-Key', TTL key ≥ 24 h.
Repeat delivery with exponential pause, ordinal processing (per player).

Example of a collbeck (payout):


POST /wallet/payouts
Idempotency-Key: 4f9f-...
{
"player_id": "u_57291",
"round_id": "r_2025_11_02_15_23_05",
"bet_id": "b_1001",
"amount_minor": 360000,
"currency": "EUR"
}

Lobby settings and promotional tools

Table catalogs: grouping by dealer languages, limits, VIP levels, disciplines.
Promo: banners, tournaments, missions/quests, hot numbers events, top wins.
Geo filters: whitelist/blacklist jurisdictions, local formats of responsible play.
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; on failure - transparent're-join '.
Quotas/Rate limits: limit of WS connections, subscriptions and rate changes.
Degradation: fallback on HLS, "lite-UI" for weak devices.

Safety and compliance

Encryption: TLS 1. 2+, HSTS; media in SRTP (WebRTC).
Access: JWT with short TTL, IP allowlist for collabs, mutual-TLS as agreed.
PII-minimization: masking of identifiers, logs without open personal data.
Anti-fraud: behavior signals (abnormal betting frequency, multiple sessions, suspicious ASN/VPN), risk flags and throttling.
Regulatory: support for self-exclusion mechanisms, local warnings, consent to cookies in the region.

Monitoring, Reporting and SLAs

What we measure

Uptime media/WS, average latency,% frame-drops, collback errors.
'Launch → First Bet'conversion, distribution of failures by causes.
Desk load, average check, ROI promo, discipline/language retention.

SLO/SLA (landmarks)

Media uptime ≥ 99. 9%, API uptime ≥ 99. 95%.
Collbecks: p95 <500 ms within the region.
WS-re-connect: p95 recovery <3-5 s.

Dashboards/alerts

Real-time metrics, round _ id/bet _ id/callback _ id'correlation.
Incident panel with causes/stakeholders and communication regulations.

Testing and acceptance

1. Sandbox: individual keys, dummy round outcomes, coefficient test tables.
2. E2E cases: successful/rejected bets, WS breaks, repeated 'PAYOUT', limit conflicts.
3. Loadings: 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 and ledger reports by amounts/rounds/statuses.

Integration best practices

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

Checklists

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

L10n: languages, currencies, formats
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 negotiated CSP/' X-Frame-Options'.
Are there Bet Behind/Speed modes? Yes, for selected tables - by configuration.
How to handle cliffs? Auto-reconnect, restore subscriptions, idempotent collabs.
Tournaments/missions available? Yes, through built-in promo widgets and analytics events.
How does reconciliation work? Provider publishes round/transaction reports; the operator checks with the ledger by'round _ id/bet _ id '.

Total

OnAir Entertainment is a strong Live provider with modern streaming and structured integration. Following the described patterns (SSO, WebRTC + WS, collbecks with idempotency, SLO monitoring, RG/compliance), the operator gets a predictable connection, stable operation during peak hours and an understandable economy of the Live vertical.