Comment le casino connecte les fournisseurs en direct via bridge

Qu'est-ce qu'un pont dans le contexte d'un casino en direct

Bridge est une couche entre la plate-forme de l'opérateur et les fournisseurs de services en direct (Evolution, Pragmatic Live, Ezugi, TVBet, etc.) qui normalise les API, les événements, les logs et les finishts. En termes simples, bridge rend une douzaine d'intégrations différentes « par vue » les mêmes : un contrat de taux unique, un schéma de statut de round unique, des webhooks monotones et des rapports.

Pourquoi il est nécessaire

Contrat unique pour des dizaines de fournisseurs (moins de changements dans la plate-forme).

Idempotence et protection contre les prises (retraits en réseau, reconnect du joueur).

Normaliser le répertoire (tables, limites, side-bets, locals).

Une seule caisse et des règles de risque (limites, AML/KYT, RG).

Surveillance des stries QoS et SLA par les fournisseurs.

Chaîne de composants

1. Plateforme Casino (hôte) : comptes, KYC/RG, bonus, portefeuille, front.

2. Bridge : adaptateurs de fournisseurs, bus d'événements, mapping de tables/limites, calcul final, logging, webhooks.

3. Live-Provider : stream (généralement WebRTC/HLS), moteur de jeu, calcul des résultats, revendeurs.

4. Portefeuille : Seamless (le solde est conservé par l'opérateur) ou Transfer (dépôt à la banque du jeu auprès du fournisseur).

5. Observabilité : métriques de strim (FPS, RTT, tampon), métriques d'entreprise (Bet, GGR, Hold).

Protocoles et sessions réseau

Vidéo :

WebRTC est une faible latence (100-500 ms), ICE/STUN/TURN est nécessaire.
HLS/LL-HLS - la latence est plus élevée, mais le CDN est plus facile.
Tarifs et événements : WebSocket/HTTP-SSE/REST.
Jetons : JWT/opaque à courte durée de vie (TTL 3-10 min), rotation à la demande du fournisseur.

Modèles de portefeuille

1) Seamless wallet (recommandé)

Le taux/paiement passe par le pont dans le portefeuille de l'opérateur.

Avantages : équilibre unique, contrôle instantané des limites, RG simplifié.

Inconvénients : exigences strictes en matière de disponibilité du portefeuille (SLA).

2) Transfer wallet

Le joueur transfère les fonds à la « banque de table » du fournisseur.

Avantages : moins de charge sur le portefeuille de l'opérateur pendant les pics.

Inconvénients : retours plus difficiles, reconcile et contrôle AML, friction en UX.

Cycle de vie de la session (seamless)

1 ./createSession → bridge crée 'sessionId', renvoie 'streamUrl',' betSocketUrl'.

2. Le Front ouvre le lecteur (WebRTC/HLS) et la connexion des événements.

3. Le joueur parie → 'placeBet' dans le pont ('idempotencyKey', 'roundId', 'selection', 'stake').

4. Bridge autorise le montant (hold) dans le portefeuille → confirme le fournisseur.

5. Le fournisseur déclare 'bettingClosed' → spin/deal → 'roundResult'.

6. Bridge calcule le paiement, charge/retourne hold, génère 'transactionId'.

7. Bridge envoie un webhook à la plate-forme (« roundId », « result », « payout », « balanceAfter »), écrit dans le ledger.

8. Fin/reconnexion - par "sessionId' (idempotent).

Contrat d'événements (exemple)

Taux → pont (WS/REST) :

json
{
"type": "bet. place",  "idempotencyKey": "c0a4-77f…",  "sessionId": "sess_abc123",  "roundId": "R-2025-10-17-18:45:03-Table23",  "selection": [{"market":"roulette_straight","value":"17"}],  "stake": {"amount":"5. 00","currency":"EUR"},  "limitsProfile":"VIP_A"
}

Réponse du pont :

json
{
"status":"accepted",  "balanceHold":"-5. 00",  "betId":"bet_9f2…",  "effectiveLimits":{"maxBet":"5000. 00"}
}

Résultat du cycle → plateforme (webhook) :

json
{
"event":"round. settle",  "roundId":"R-2025-10-17-18:45:03-Table23",  "bets":[
{"betId":"bet_9f2…","stake":"5. 00","payout":"180. 00","outcome":"WIN"}
],  "transactions":[
{"id":"trn_bet_9f2…","type":"DEBIT","amount":"5. 00"},   {"id":"trn_pay_9f2…","type":"CREDIT","amount":"180. 00"}
],  "balanceAfter":"1320. 40"
}

Règles clés :

Idempotence : toutes les demandes avec 'idempotencyKey'.
Typage clair des résultats : 'WIN/LOSE/PUSH/VOID/RETRY'.
Identifiants stables : 'roundId' est globalement unique (tableau + temps + shard).

Catalogue et limites

Discovery : '/providers/: id/tables '- liste des tables, limites, side-bets, langues, planning.

Pools de limites : 'DEFAULT', 'VIP _ A', 'VIP _ B', 'Ultra'.

Règles de mapping : pays/monnaie/statut KYC → tables autorisées et profils limites.

Changement de limite chaude : événements 'limites. update 'sans redémarrer la table.

Observabilité et qualité des stries (QoS)

Métriques par joueur :

RTT des signaux de mise (cible <150 ms WebRTC).
Dropped frames / buffer events.
Adaptation Bitrate/Résolution.
Bet window latency (le temps entre 'bettingOpen' et l'acceptation réelle du pari).

Métriques par fournisseur/bureau :

Aptyme de table, rounds aborted, late settlements, fréquence "VOID'.
Temps moyen après la fermeture des paris.
QoS alerte : dégradation du FPS, éclats de « retry ».

Conformité et sécurité

KYT/AML : analyse des sources de dépôt, drapeau « risque élevé » → interdiction des paris en direct.

RG (jeu responsable) : temporisation, limites, auto-exclusion - s'appliquent jusqu'à placeBet.

Résidence de données : la logique et le PII sont stockés chez l'opérateur ; bridge ne garde que le matériel. revues et agrégats.

Sécurité de transport : mTLS/IP-whitelist aux fournisseurs, signature des requêtes HMAC, TTL court tokens.

Audit : ledger immuable (WORM/append-only), export par 'roundId '/' sessionId'.

Calcul, récupération et retours

On-the-fly settle : débit instantané/crédit pour chaque résultat.

Batch reconcile : rapprochement des rapports du fournisseur (hourly/daily) avec le ledger bridge (P&L, commission).

Script VOID/REFUND : échec du strim, erreur du revendeur, argument - retour partiel/complet avec des codes de cause clairs.

Dispute Center : le groupe 'roundId' ↔ l'enregistrement vidéo (code temporel) pour que le support résout rapidement les tickets.

Performances et tolérance aux pannes

Skaling : Adaptateurs stateless des fournisseurs + Kafka/NATS comme bus d'événements.

Stockage : chaud (Redis) pour les sessions/limites, chaud (Postgres) pour le ledger, froid (S3) pour les logs.

Folbacky : si le portefeuille ne répond pas - 'SOFT _ DECLINE' avec des retraits ; Si le fournisseur n'est pas disponible - désactiver les tables/cacher dans le hall.

Retraits idempotent : selon les temporisations du réseau, répéter 'placeBet '/' settle' en toute sécurité.

UX : schémas frontaux

Synchronisation de l'horloge : utilisez 'serverTime' de bridge pour les minuteries « Fermer les paris »....

Localisation : langue du revendeur ≠ langue de l'interface ; afficher les sous-titres/glossaire des termes.

Stream Player : auto-fallback WebRTC → LL-HLS en cas de mauvais réseau.

Error UI : codes compréhensibles ('LBRG-401 TOKEN_EXPIRED',' LBRG-429 LIMIT_EXCEEDED', 'LBRG-503 PROVIDER_DOWN').

Multitâche : switch rapide des tables sans rupture de session (reuse 'sessionId').

Anti-modèles

Stocker des jetons de longue durée sur le client.

Accepter le pari après 'bettingClosed'en raison d'un dilei - le litige est garanti.

L'absence de 'idempotencyKey' → les prises lors des retraits.

Mélanger les zones time dans roundId et les rapports.

Fixez des limites « par œil » sans profils ni statut KYC.

Ignorer QoS strim est un churn haut sur les réseaux mobiles.

Plan de mise en œuvre étape par étape (chèque)

Architecture et contrats

Fixer un seul contrat d'événement : 'bet. place`, `bet. accepted`, `bet. rejected`, `round. settle`, `limits. update`, `session. close`, `provider. error`.
Définissez l'idempotency et les formats roundId, betId, transactionId.
Sélectionnez le modèle de portefeuille (Seamless en priorité).

Sécurité

mTLS aux fournisseurs, webhooks signature HMAC, token TTL ≤ 10 minutes.
Politique RG/AML/KYT avant l'admission aux taux, audit-journal.

Catalogue et limites

Importations de tables et de profils limites, mapping par pays/devises/CUS.
Mise à jour à chaud des limites et des statuts des tables.

Frontende

Lecteur WebRTC avec folback LL-HLS, horloge de synchronisation, timer de mise stable.
Codes d'erreur et messages humains.

Plan de test

Scénarios de haute latence/packet-loss, reconnaissance sans perte de taux.
Double clic de taux → un seul débit (idempotence).
VOID/REFUND, rounds controversés, divergences de rapports.

Observabilité

Дашборд QoS: RTT, dropped frames, aborted rounds, time-to-settle.
Alertie sur le fournisseur SLA, rapports reconcile.

Bridge transforme le « zoo » des intégrations en direct en un système géré : des tarifs uniques, des calculs uniques, un UX prévisible et un contrôle transparent de la qualité des stries. Avec un pont bien conçu, l'opérateur connecte plus rapidement les nouveaux fournisseurs en direct, réduit les risques technologiques et protège P&L grâce à l'idempotence, à des limites strictes et à une observabilité claire.