Check-list d'intégration API casino : ce qu'il faut construire, tester et surveiller avant la mise en ligne

Dernière vérification 2026-10-09

Une intégration d'API de jeux de casino échoue toujours aux mêmes endroits : un débit rejoué facturé deux fois, un rollback sur une mise jamais reçue, une devise à trois décimales. Cette check-list passe chaque couche en revue dans l'ordre où un développeur la rencontre, avec la panne que chaque point évite.

Cette check-list d’intégration d’API casino s’adresse au développeur qui a les clés API et une échéance. Elle suit l’ordre dans lequel on rencontre les choses en pratique : d’abord le contrat entre votre wallet et le fournisseur, puis le lobby, puis le lancement, puis les tests et la première semaine en production.

Chaque point existe parce que quelque chose casse sans lui. Cochez-les dans un document partagé, et envoyez les points ouverts à l’équipe d’intégration du fournisseur sous forme de questions.

0. Avant la première ligne de code

• Vous avez la documentation API complète, pas un PDF commercial : chaque endpoint, chaque code d’erreur, des exemples de payloads.
• Vous connaissez le modèle de wallet. Seamless (le fournisseur appelle votre serveur à chaque mise et chaque gain) ou transfer (vous transférez l’argent vers un solde côté fournisseur). Cette check-list part du seamless, ce que vendent la plupart des agrégateurs.
• Les identifiants et l’URL de callback de staging sont distincts de ceux de production.
• La signature des requêtes est claire : quel en-tête, quel algorithme (généralement HMAC-SHA256), quels champs sont signés, dans quel ordre.
• Vous connaissez les adresses IP sortantes du fournisseur, s’il vous demande de les mettre en liste blanche.
• Vous avez un contact technique nommé et un canal qui répond dans l’heure ou presque.

1. Callbacks wallet

Le fournisseur appellera votre serveur pour quatre choses. Construisez-les avant tout le reste.

• Balance. Renvoie le solde disponible du joueur, dans sa devise.
• Debit (mise). Retire la mise si les fonds le permettent, renvoie le nouveau solde. Un solde insuffisant renvoie le code d’erreur documenté, pas une erreur 500.
• Credit (gain). Ajoute le gain. Un crédit à zéro est valide et doit réussir ; beaucoup de studios l’envoient pour clore un tour perdant.
• Rollback (remboursement). Annule un débit précis antérieur.
• Chaque réponse est signée ou validée comme l’exige la documentation.
• Vous vérifiez la signature entrante à chaque appel et rejetez les mauvaises avec le code documenté.
• Votre endpoint répond largement sous le timeout du fournisseur. Trouvez le chiffre dans la doc. S’il est de 3 secondes, visez moins de 300 ms au 99e centile.
• Les montants sont stockés en entiers dans la plus petite unité, ou en décimaux à virgule fixe. Jamais en flottants.
• Debit et credit portent un identifiant de tour et un identifiant de jeu. Stockez les deux.

Cas concret. Un joueur sur une connexion mobile lente lance un spin. Votre débit réussit, mais la réponse met 4 secondes et le fournisseur abandonne à 3. Il envoie alors un rollback, ou rejoue le débit, selon ses règles. Les sections 2 et 3 existent pour ce moment précis.

2. Idempotence

• Une contrainte d’unicité porte sur l’identifiant de transaction du fournisseur dans votre table des transactions.
• Un débit ou un crédit répété avec le même identifiant ne fait plus bouger d’argent. Il renvoie la réponse d’origine, avec les mêmes soldes.
• Un appel répété avec le même identifiant mais un montant différent est rejeté et journalisé bien en évidence. C’est un bug du fournisseur ou une attaque.
• Mise à jour du solde et insertion de la transaction se font dans une seule transaction de base de données. Aucun instant où l’une existe sans l’autre.
• Les appels simultanés pour un même joueur sont sérialisés (verrou de ligne ou équivalent). Deux débits simultanés depuis deux onglets de jeu ne doivent pas passer tous les deux sur un solde qui n’en couvre qu’un.

3. Rollbacks

• Un rollback référence le débit qu’il annule. Retrouvez-le par l’identifiant de transaction du fournisseur.
• Rollback d’un débit jamais reçu : enregistrez-le comme marqueur (tombstone) et renvoyez un succès (ou le code documenté). Si le débit arrive ensuite, le marqueur vous empêche de le prélever.
• Rollback d’un débit déjà annulé : renvoyez la réponse d’origine.
• Rollback d’un débit dont le tour a déjà un gain : suivez la doc à la lettre. Certains fournisseurs l’interdisent, d’autres attendent que vous annuliez les deux.
• Les rollbacks ne laissent jamais un solde dans un état inexplicable. S’ils peuvent le rendre négatif, fixez la règle maintenant et écrivez-la.

4. Tours et parties inachevées

• Vous voyez quels tours sont ouverts (débit reçu, pas de crédit de clôture).
• Vous savez comment le fournisseur clôt les tours restés en suspens : crédit automatique après un délai, outil manuel ou ticket au support.
• Les gains bonus et free rounds sont marqués pour que votre logique bonus les traite différemment des gains cash.
• Votre back-office affiche l’historique complet des tours par joueur : chaque appel, chaque réponse, avec horodatage.

5. Devises

• Chaque joueur a une devise fixe, définie à l’inscription, envoyée au lancement et renvoyée dans chaque callback.
• Vous vérifiez que la devise du callback correspond à celle du joueur, et rejetez les écarts.
• Le nombre de décimales est correct par devise. La plupart des devises fiat en ont deux, certaines zéro, d’autres trois. La crypto peut en avoir huit ou plus ; mettez-vous d’accord avec le fournisseur sur la précision utilisée dans les échanges.
• Chaque jeu listé prend réellement en charge la devise dans laquelle vous l’affichez. Un studio peut gérer l’EUR et l’USD, mais pas la BDT ni l’ETB.
• Les limites de mise par devise ont du sens. Une mise minimum modeste en EUR peut devenir bizarre en IDR ou énorme en BTC.
• Devise d’affichage et devise de règlement ne sont pas mélangées dans les rapports.

6. Synchronisation de la liste des jeux

• La liste des jeux est récupérée par l’API à intervalle régulier, au moins quotidien, et stockée localement.
• Les jeux désactivés ou retirés disparaissent du lobby à la synchro suivante, pas au trimestre suivant.
• Les nouveaux jeux arrivent en statut « à valider », pas directement dans le lobby, si vous faites de la curation.
• Vous stockez l’identifiant de jeu stable du fournisseur, pas le nom. Les noms changent.
• Les images sont mises en cache chez vous ou servies dans une taille adaptée au mobile.
• Chaque jeu porte sa catégorie, son studio, les appareils et les devises pris en charge, pour que les filtres du lobby ne mentent pas.
• Les studios désactivés sur un marché sont filtrés par vos propres règles, pas laissés au hasard.

7. URL de lancement

• Le lancement en argent réel transmet un jeton de session de courte durée lié au joueur. Jamais un mot de passe ni un identifiant réutilisable.
• L’expiration du jeton est gérée : un vieil onglet affiche un message clair, pas une frame cassée.
• Langue, devise, type d’appareil et URL de retour vers le lobby sont définis au lancement.
• Une URL de dépôt ou de caisse est transmise quand le jeu le permet, pour que « fonds insuffisants » mène quelque part.
• Le jeu s’ouvre correctement en iframe comme dans une nouvelle fenêtre. Certains studios bloquent les iframes sur certains domaines ou navigateurs.
• Les lancements en mode démo, s’ils existent, ne touchent jamais le vrai wallet. Testez-le explicitement.
• Le délai entre le clic et la première image est mesuré sur un téléphone milieu de gamme en 4G. Au-delà de 5 secondes, vous perdez des joueurs.

8. Tests

• Un joueur de test par devise prise en charge.
• Un tour complet par type de jeu : slot, table live, crash, jeu de table, virtuel.
• Pannes provoquées : votre serveur renvoie un timeout, une erreur 500, un code fonds insuffisants. Observez la réaction du fournisseur.
• Appels en double rejoués à la main : débit deux fois, crédit deux fois, rollback deux fois.
• Appels dans le désordre : rollback avant débit, crédit après rollback.
• Deux onglets, même joueur, qui jouent en même temps.
• Expiration de session en pleine partie.
• Un gros gain et un gain nul.
• Votre rapport de réconciliation correspond au rapport du fournisseur sur la période de test, au centime près.

9. Mise en ligne

• Clés et URL de callback de production en place, staging désactivé pour les joueurs réels.
• Monitoring de la latence des callbacks, du taux d’erreur et des échecs de signature, avec des alertes envoyées à une personne, pas à un tableau de bord que personne n’ouvre.
• Tâche de réconciliation quotidienne : vos totaux par jeu et par devise face à ceux du fournisseur.
• En modèle prépayé, une alerte de crédit bas bien au-dessus de zéro, et quelqu’un capable de recharger un dimanche.
• Un interrupteur d’arrêt d’urgence par jeu et par studio dans votre back-office.
• Le canal de support du fournisseur et le contact d’escalade notés dans votre runbook.

10. Les sept premiers jours

• Vérifiez la réconciliation chaque matin.
• Passez en revue tous les callbacks rejetés et les tours ouverts.
• Surveillez les erreurs de lancement par studio ; un seul mauvais studio peut plomber un lobby.
• Demandez au fournisseur ses propres journaux d’erreurs et comparez.

Une petite équipe qui lance une marque crypto peut venir à bout de cette liste en une semaine si la documentation du fournisseur est solide. Si la doc est maigre, la liste sert aussi de test du fournisseur : comptez le nombre de points sur lesquels vous avez dû poser une question. Le classement seamless wallet et la page agrégateurs pour nouveaux opérateurs notent les fournisseurs précisément sur ce type de travail d’intégration.