Comment fonctionne l'API de connexion des jeux Vie à la plate-forme

1) Architecture générale et rôles des composants

Plate-forme de l'opérateur (Casino Platform) : comptes, portefeuille, moteur bonus, limites, KYC/AML, journal des transactions.

Fournisseur de jeux en direct (Studio/Provider) : studios, revendeurs, flux vidéo (WebRTC/Low-Latency HLS), serveur de jeux.

Agrégateur (parfois) : API unique à des dizaines de fournisseurs, unification des devises/limites/événements.

Frontend client : client web/mobile avec paris UI, lecteur vidéo, chat, conseils locaux.

Services auxiliaires : Risk/Anti-fraud, Loging, Analytics, Messages Queuing (Kafka/RabbitMQ), Monitoring.

Topologie type : Client → (JWT) → plate-forme → (server-to-server) → fournisseur, en parallèle, le client reçoit le flux vidéo du CDN/pool de serveurs multimédias.

2) Le cycle de vie du joueur et les sessions

2. 1. Login et « token de jeu »

1. Le joueur est autorisé sur la plateforme.

2. La plate-forme appelle CreateGameSession du fournisseur (S2S), passe « player _ id », « currency », « country », « bet _ limits », les drapeaux du jeu responsable.

3. Le fournisseur renvoie un game_token et un launch_url jetables.

4. Le client ouvre 'launch _ url' dans l'iframe/un nouvel onglet en ajoutant 'game _ token' (ou obtient 302 sur l'URL finale du jeu).

Exemple de requête S2S :

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

Réponse du fournisseur :

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

2. 2. Authentification à l'avant

Le jeu est téléchargé, validé 'game _ token' via son beckend.

WebSocket est installé sur le serveur de jeu pour les paris/événements.

Le flux vidéo passe par WebRTC (faible latence 0. 5-2 c) ou LL-HLS (2-5 c).

3) Argent et taux : Wallet API et idempotence

3. 1. Solde et débit/crédit

Le fournisseur ne stocke pas l'argent du joueur - il appelle Platform Wallet API :

`GET /wallet/balance? player_id' → actuellement disponible.
'POST/wallet/debit '→ débiter le taux.
'POST/wallet/credit '→ créditer les gains/retours.
'POST/wallet/rollback '→ annuler la transaction lors de l'annulation de la ronde.

Important : toutes les transactions monétaires sont idempotentes par 'transaction _ id '/' round _ id'. Répéter la même requête ne change pas le résultat.

Exemple de débit (taux) :

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. Temps et statuts de mise

WINDOW_OPEN → WINDOW_CLOSING → WINDOW_CLOSED. Après 'WINDOW _ CLOSED', le fournisseur interdit les nouveaux débits.

Les paris tardifs sont rejetés avec le code 'LATE _ BET'.

En cas de rupture de communication, le client peut réémettre le pari - le serveur doit être capable de distinguer le duplicata par Idempotency-Key.

États des transactions : 'PENDING', 'SETTLED', 'ROLLED _ BACK', 'REJECTED'.

4) Round Events : Modèle et priorité

4. 1. Schéma des événements WebSocket

`round. started '→ vient' round _ id ', le compteur de paris.

`bet. acceptés/référés '→ confirmation à chaque taux.

`round. closed '→ les paris ne sont plus acceptés.

`round. result '→ exode (secteur roulette/carte/os).

`payout. creat' → le montant du gain par joueur.

`round. settled '→ statut final, somme de contrôle.

Exemple d'événement de résultat :

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. Cohérence et montants de contrôle

Chaque événement est fourni avec 'seq' et 'signature' (mTLS + signature du corps de requête).

Pour la reconnaissance, "payout _ checksum" est spécifié - la somme de tous les crédits de "round _ id'doit converger.

5) Flux vidéo et retard

Le WebRTC pour les paris à main vivante (blackjack/baccara/roulette) est un budget strict de retard <2 c avant le client.

LL-HLS/DASH pour les spectateurs/échelle, permet 2-5 c.

Synchronisation temporelle : NTP/chrony, dans payload - 'video _ ts'pour les répliques et les controverses.

Folback : en cas de dégradation du WebRTC, → auto-basculement vers LL-HLS avec verrouillage des paris tardifs.

6) Erreurs, retraits, délais

Règles générales :

Tous les appels S2S avec un délai de 800-1500 ms, des retraits avec pause exponentielle et Jitter, mais sans rééchelonnement (idempotence).

Codes d'erreur du portefeuille :

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

Format d'erreur :

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

7) Bonus, frispins, assurances

Parallèlement au portefeuille « cash », il peut y avoir un solde bonus : payload indique la source du débit 'source : CASH	BONUS`.
Pour les jeux de vie, les assurances/side-beth (par exemple, dans le blackjack) sont des transactions séparées avec leurs propres limites et coefficients.
Règles d'arrondi : bancaire (half-to-even) ou en faveur d'un joueur/opérateur - doit être enregistré dans le config d'intégration.

8) Jeu responsable et restrictions

Drapeaux de session : 'self _ excluded', 'cooldown _ until', 'loss _ limit _ left', 'time _ limit _ left'.

Le fournisseur peut demander « validate _ limits » avant chaque débit.

La plate-forme peut lancer un force_close_session : le joueur est exclu/a dépassé la limite → le fournisseur ferme la fenêtre de paris et effectue des retours sur les paris non payés.

9) Sécurité et conformité

mTLS pour S2S, HSTS, IP-allowlist strict.

JWT/JWS avec un court TTL pour les tokens de première ligne, vérification audience/issuer.

Signature webhook du fournisseur (HMAC-SHA256 au-dessus du corps).

Logs d'action des revendeurs, relais de round, audit immuable (stockage WORM).

Stockage des données personnelles - minimisation des PII, tokenization "player _ id', durée de conservation par juridiction (GDPR et équivalents).

Géo-blocage et interdictions par juridiction au niveau de CreateGameSession.

10) Reconnaissance et finances

10. 1. Rapports horaires/journaliers

Le fournisseur fait un rapport sur « round _ id → total_bets, total_wins, fees ». La plate-forme résume :

Montant des débits = Σ des paris, Montant des crédits = Σ des gains + remboursements, Delta = GGR (compte tenu des bonus/jackpots/commissions).

Format du rapport :

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. Scripts Rollback

Échec de la vidéo/storyboard → round. cancelled : le fournisseur casque « rollback » tous les paris de la ronde.

Le traitement double du débit attrapé sur le quai → ' DUPLICATE_TRANSACTION ' et 200 OK avec l'ancien résultat.

11) Chat, modération et événements UI

Les événements de chat passent par un canal distinct (WebSocket n ° 2) avec des filtres par mots stop.

Annonces système (close bets, winner list) - uniquement à partir d'une source de confiance du fournisseur, signées/temporisées.

12) Essais et certification

Sandbox du fournisseur : résultats fixes, possibilité de forcer le round. result`.

Circuit QA : table de test avec fenêtres de paris coupées (5-8 c) et flow accéléré.

Charge : simulation de 5 à 10 000 joueurs simultanés, débits de pointe par seconde (TPS) ≥ × planifié 1. 5.

Certification d'intégration : checklists par idempotence, devises, arrondissements, traitement des déconnexions, respect des limites et self-exclusion.

13) Métriques et SLO

Ceci : median/95p latency pour 'debit/credit', WebSocket round-trip, erreur de synchronisation temporelle, drop-rate WebRTC.

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

Exemples de SLO :

99. 5% `debit` ≤ 1. 2 s, 99. 9 % livraison 'round. result '≤ 300 ms après la fixation, Vidéo ≤ 2. 5 s pour 95p WebRTC.

14) Multivalut, taxes, localisation

Conversion - hors fournisseur : le jeu fonctionne strictement dans la devise de la session.

Taxes/retenues - côté plateforme sous 'credit' (champ 'withholding').

Localisation : 'lang', format nombres/devises, fuseau horaire pour les minuteurs et les rapports.

15) Options d'intégration

1. Direct-to-Provider : un maximum de contrôles et de fiches, mais des contrats/certifications séparés.

2. Via l'agrégateur : couverture rapide par les fournisseurs, circuits unifiés, parfois moins de flexibilité.

3. Hybride : Top tables directement, le reste à travers l'agrégateur.

16) Mini-spécification (total)

16. 1. WebSocket entrants (du client au fournisseur)

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

16. 2. WebSocket sortant (du fournisseur au client)

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 (plate-forme ↔ fournisseur)

« POST/wallet/debit » (idempotent)

« POST/wallet/credit » (idempotent)
« POST/wallet/rollback » (idempotent)

Signature HMAC, 'Timestamp', 'Nonce', protection contre les répétitions (TTL ≤ 60 c).

17) Mallettes de bord et comment les fermer

Rupture de connexion chez le joueur : pari envoyé, pas de confirmation → répétition avec la même 'Idempotency-Key' ; le serveur répondra avec l'état précédent.

Changement de dealer/deck dans le tour : annulation automatique et complet 'rollback'.

Non-correspondance de la monnaie : 'CURRENCY _ MISMATCH' + journal de l'événement ; le jeu est bloqué jusqu'au dépassement de la session.

Self-exclusion au moment du jeu : « force _ close _ session » immédiat, retour des non joués.

Changement de qualité vidéo : client uniquement, sans impact sur les minuteries/paris.

Re-handshake WebSocket : sans perte d'ordre - la file d'événements avec 'seq', le « rattrapage » des manqués.

18) Chèque-liste de production-lancement

Sécurité

mTLS + pinning certificat, IP-allowlist.
Signature de tous les webhook's et vérification de 'Timestamp '/' Nonce'.
Mini-PII : seulement "player _ id' (tokenisé).

Fiabilité

L'idempotence de toutes les transactions monétaires.
Répliques de rounds et vérification inaltérable.
Auto-folback WebRTC → LL-HLS.

Produit

Les limites/jeux responsables sont appliqués en temps réel.
Indices natifs au moment du pari.
Dashboards SLO + alertes 24/7.

L'API d'intégration des jeux de vie est un ensemble de strim de bas niveau, de bus d'événement et de portefeuille idempotent avec des exigences strictes en matière d'ordre des messages, de temps et de sécurité. Une mise en œuvre réussie repose sur un cycle de vie rigoureux des paris et des rounds, une cohérence vérifiable, une protection des données et des limites de jeu responsable - et transforme une « belle diffusion » en un produit financier fiable et certifiable.