Plateforme B2B d’agrégation de jeux de casino

Une API. Un catalogue. Un grand livre.

Une couche d’intégration unifiée pour les opérateurs : agrégez le contenu casino, contrôlez qui peut lancer quoi et conservez chaque mouvement de portefeuille dans un grand livre auditable.

Demander une démo Découvrir la plateforme

API REST versionnéeContrat OpenAPI
Grand livre idempotentÉcritures en ajout seul
Isolation des locatairesDonnées par opérateur
EN · FR · ARPrise en charge RTL complète

Vue d’ensemble de la console de la plateforme, avec des données sandbox simulées — Écrans réels de l’application en fonctionnement · données sandbox simulées

Portail opérateur sur téléphone, avec des données sandbox simulées — Écrans réels de l’application en fonctionnement · données sandbox simulées

Nos solutions

Tout ce dont la couche d’agrégation a besoin, sur une seule plateforme

Six domaines de la plateforme, tous implémentés et testables dès aujourd’hui dans le bac à sable.

Agrégation de jeux

Les jeux des fournisseurs normalisés dans un seul catalogue. Les jeux retirés sont archivés, jamais supprimés.

Gestion des fournisseurs

Cycle de vie, santé, identifiants et historique de synchronisation de chaque adaptateur.

Catalogue opérateur

Chaque opérateur active, met en avant et ordonne exactement les jeux qu’il peut proposer.

Gestion des opérateurs

Locataires, rôles, clés API à portée limitée, blocages par pays et historique d’audit complet.

Analyses et rapports

Rapports de revenus par devise, règlements et rapprochement des relevés.

Infrastructure d’intégration

Webhooks signés avec nouvelles tentatives, API REST versionnée et bac à sable.

Choisissez votre intégration

Quatre façons de démarrer, sans grille tarifaire

Les conditions commerciales sont définies projet par projet. Choisissez la voie qui correspond à votre situation et nous cadrerons le reste ensemble.

Disponible aujourd’hui

Évaluation en bac à sable

Fournisseur et crédits simulés
Portail opérateur et clés API
Grand livre et rapports complets
Aucune opération en argent réel

Demander une démo

La plus directe

Disponible aujourd’hui

Intégration par API REST

API REST v1 versionnée
Contrat OpenAPI
Opérations de portefeuille idempotentes
Webhooks signés avec nouvelles tentatives

Lire la documentation API

Disponible aujourd’hui

Portefeuille détenu par l’opérateur

Rappels de portefeuille signés
Récupération des issues inconnues
Les soldes restent chez l’opérateur
Rapprochement avec le grand livre

Parler à l’équipe

Pas encore intégré

Intégration de fournisseurs

Contrat d’adaptateur et capacités
Construit d’après la documentation officielle
Identifiants stockés en écriture seule
En production après tests vérifiés uniquement

Voir l’état des intégrations

Pourquoi cette plateforme

Conçue pour les opérateurs qui veulent garder le contrôle

API unifiéeUn seul contrat versionné
Isolation des locatairesAppliquée et testée
Grand livre immuableAjout seul, idempotent
Audit et webhooksChaque changement tracé
Trois languesAnglais, français, arabe

Standards d’intégration

Des interfaces standard, sans logos empruntés

Ce sur quoi vous pouvez vous intégrer aujourd’hui. Les partenariats avec des fournisseurs ne sont annoncés qu’une fois l’intégration vérifiée.

REST / JSON
OpenAPI 3
Webhooks signés HMAC
Clés d’idempotence
Export CSV
Environnement bac à sable
Adaptateurs de fournisseurs · pas encore intégrés

Tableau de bord du portail opérateur avec des données sandbox simulées

Voyez-le en action

Explorez la console en direct

Parcourez le registre des fournisseurs, le contrôle du catalogue, le grand livre et les rapports avec un opérateur sandbox. Tout ce que vous voyez fonctionne avec des crédits simulés.

Demander une démo Lire la documentation API

Architecture de la plateforme

Du fournisseur au registre rapproché, un seul chemin.

Les mêmes six couches existent aujourd’hui dans le code. La première est représentée par un fournisseur simulé, jusqu’à l’ajout d’intégrations réelles et autorisées.

Fournisseurs autorisés
Fournisseur bac à sable (simulé) · les autres ne sont pas connectés
↓
Couche d’adaptateurs
Authentification · catalogue · lancement · rappels
↓
Cœur d’agrégation
Catalogue · sessions · registre de portefeuille · rapports · audit
↓
Opérateurs
API REST v1 · rappels de portefeuille

Schéma conceptuel. Seul le fournisseur simulé en bac à sable est disponible aujourd’hui ; les autres fournisseurs ne sont pas connectés.

Implémenté (fournisseur sandbox simulé)Pointillés : emplacement de fournisseur, non connecté

Fournisseurs autorisés
Fournisseur simulé en bac à sable aujourd’hui ; les autres seulement après documentation, identifiants et tests vérifiés.
Couche d’adaptateurs de fournisseurs
Des adaptateurs typés gardent la signature, le HTTP et les erreurs propres à chaque fournisseur hors des contrôleurs et de la logique de portefeuille.
Cœur d’agrégation unifié
Catalogue normalisé, règles de disponibilité, isolation des locataires, piste d’audit.
Catalogue de jeux et sessions de lancement
Des sessions à durée limitée dont les jetons ne sont stockés que sous forme de hachage.
API opérateur et rappels de portefeuille
API REST pour les opérateurs et rappels signés des fournisseurs, tous deux idempotents.
Rapports et rapprochement
Rapports par devise, règlements et rapprochement avec les relevés des fournisseurs.

Spécifications de la plateforme

La plateforme, en toute précision.

Ce qui est réellement implémenté aujourd’hui, énoncé simplement. Rien dans ce tableau n’est une promesse de feuille de route.

Modèle de connexion: API REST v1 versionnée avec contrat OpenAPI, rappels signés des fournisseurs et webhooks signés vers les opérateurs.
Catalogue de jeux: Jeux des fournisseurs normalisés dans un modèle unique. Les jeux retirés par un fournisseur sont archivés, jamais supprimés : l’historique reste intact.
Contrôle opérateur: Disponibilité des jeux par opérateur, mise en avant ordonnée, blocages par pays, clés API à portée limitée avec rotation et révocation.
Portefeuille et grand livre: Grand livre idempotent, verrouillé par ligne et en ajout seul. Portefeuille sandbox interne, ou portefeuille détenu par l’opérateur via des rappels signés.
Rapports: Rapports de revenus par devise avec export CSV, règlements immuables et rapprochement des relevés avec le grand livre.
Exploitation: Identifiants de corrélation, journal d’audit, contrôles de santé et livraison de webhooks avec nouvelles tentatives bornées.
Langues: Anglais, français et arabe, avec des mises en page de droite à gauche correctes.
Fournisseurs aujourd’hui: Un fournisseur sandbox simulé est disponible. Les fournisseurs réels ne sont connectés qu’après documentation officielle, identifiants et tests d’intégration vérifiés.

FAQ

Les questions que nous attendons.

Les réponses décrivent ce qui est implémenté aujourd’hui. Pour tout le reste, posez-nous la question.

Qu’est-ce que l’agrégation de jeux ?

Au lieu d’intégrer chaque fournisseur de jeux séparément, un opérateur s’intègre une seule fois à un agrégateur. L’agrégateur se connecte aux fournisseurs, normalise leurs jeux en un seul catalogue et achemine les lancements et le trafic de portefeuille.

Comment fonctionne l’API unifiée ?

Les opérateurs appellent une API REST versionnée sous /api/v1 avec une clé porteuse : lister et lancer des jeux, appeler le portefeuille, lire transactions et rapports. L’argent est exprimé en unités mineures entières et chaque appel au portefeuille porte une clé d’idempotence. Le document OpenAPI fait foi.

Comment les intégrations de fournisseurs sont-elles configurées ?

Un administrateur de la plateforme enregistre un fournisseur, stocke ses identifiants (écriture seule, chiffrés), lance un contrôle de santé et une synchronisation du catalogue, puis le fait passer de brouillon à test puis actif. Un fournisseur hors bac à sable ne peut pas être activé sans référence d’autorisation ni tests d’intégration vérifiés.

Comment fonctionne le bac à sable ?

Un fournisseur simulé déterministe, des crédits simulés (devise XTS) et un exécuteur de scénarios pour les doublons, les rappels dans le désordre et les nouvelles tentatives. Les URL de lancement sont simulées. Les opérations en argent réel sont désactivées.

Comment les rappels de portefeuille sont-ils traités ?

Les rappels des fournisseurs sont vérifiés (signature, horodatage, nonce à usage unique pour le fournisseur bac à sable), rattachés à une session de lancement et appliqués par un seul moteur de portefeuille idempotent, verrouillé par ligne et en ajout seul. En mode portefeuille opérateur, l’opérateur reste la référence et les résultats inconnus sont annulés ou récupérés avec le même identifiant de transaction.

Comment le rapprochement est-il réalisé ?

Les relevés des fournisseurs sont importés et comparés au registre. Les lignes manquantes, différentes ou en double deviennent des exceptions que des personnes examinent et annotent ; le rapprochement ne modifie jamais l’historique du registre. Aujourd’hui, cela n’est vérifié que sur des relevés synthétiques.

Que faut-il pour démarrer une intégration ?

Pour le bac à sable : un compte opérateur et une clé API, que nous délivrons après un échange. Pour un vrai fournisseur : sa documentation, ses identifiants, un accord commercial et des tests vérifiés. Les obligations de licence et de réglementation incombent à l’opérateur.

Quelles intégrations sont disponibles actuellement ?

Uniquement le fournisseur simulé en bac à sable. Aucun studio tiers n’est présenté comme intégré, et aucun n’est sous-entendu.

Prêt à vous connecter ?

Cadrons votre intégration ensemble

Parlez-nous de votre activité et de l’avancement de votre projet. Nous organiserons une démo dans l’environnement bac à sable.

Demander une démo Contacter les ventes