Un logiciel de loterie instantan\u00e9e relie une partie, un r\u00e9sultat faisant autorit\u00e9 et son r\u00e8glement financier sans attendre un tirage programm\u00e9. Une carte \u00e0 gratter num\u00e9rique est une mani\u00e8re de r\u00e9v\u00e9ler ce r\u00e9sultat ; l’animation n’est pas l’\u00e9criture financi\u00e8re. En \u00e9valuant une plateforme de jeux \u00e0 gratter en ligne, l’op\u00e9rateur doit \u00e9tablir quand la partie est engag\u00e9e, quel syst\u00e8me est responsable du r\u00e9sultat et comment reprendre une partie interrompue.<\/p>\n
La d\u00e9cision d’int\u00e9gration d\u00e9passe donc le choix de jeux attrayants. Elle comprend l’\u00e9ligibilit\u00e9 du compte, les fronti\u00e8res du portefeuille, les versions de jeux, l’historique joueur, le reporting et le support. Ce guide transforme ces fronti\u00e8res en questions pratiques et en tests de recette.<\/p>\n\n
Un eInstant r\u00e9sout une partie selon les r\u00e8gles et le m\u00e9canisme de r\u00e9sultats convenus. Une interface num\u00e9rique \u00e0 gratter peut proposer une r\u00e9v\u00e9lation interactive, mais les r\u00e8gles doivent expliquer ce que le joueur ach\u00e8te et quand le r\u00e9sultat devient fixe. Ne supposez pas que gratter plus vite, rejouer une animation ou se reconnecter cr\u00e9e une nouvelle chance.<\/p>\n
Cela diff\u00e8re d’un ticket participant \u00e0 un tirage ult\u00e9rieur identifi\u00e9. Cela diff\u00e8re aussi d’un logiciel de point de vente qui suit les carnets physiques de tickets \u00e0 gratter, les transferts de stock ou les tickets activ\u00e9s. Clarifiez la cat\u00e9gorie achet\u00e9e avant de comparer les fournisseurs.<\/p>\n
Comparez le p\u00e9rim\u00e8tre commercial avec le guide \u00e9conomique des jeux propri\u00e9taires<\/a>, notamment droits sur les contenus, responsabilit\u00e9s op\u00e9rationnelles et co\u00fbts de modification. Une int\u00e9gration r\u00e9utilisable ne rend pas identiques les r\u00e8gles ou exigences d’approbation de chaque titre.<\/p>\n\n Convenez d’une s\u00e9quence document\u00e9e : compte \u00e9ligible, jeu et mise s\u00e9lectionn\u00e9s, autorisation d’achat, partie accept\u00e9e, r\u00e9sultat faisant autorit\u00e9, r\u00e9v\u00e9lation et r\u00e8glement. Certains syst\u00e8mes combinent des \u00e9tapes ; le contrat doit n\u00e9anmoins identifier le point d’engagement et la preuve de chaque \u00e9tat. Distinguez \u00ab le navigateur a affich\u00e9 un succ\u00e8s \u00bb de \u00ab le serveur a accept\u00e9 la partie \u00bb.<\/p>\n Attribuez un identifiant stable \u00e0 chaque partie et associez r\u00e9f\u00e9rence joueur, jeu et version, devise, mise et r\u00e9f\u00e9rence du r\u00e9sultat. D\u00e9finissez si le r\u00e9sultat provient d’un m\u00e9canisme RNG ou d’un r\u00e9sultat attribu\u00e9 selon le mod\u00e8le document\u00e9. Demandez quel composant le g\u00e9n\u00e8re, le conserve et le v\u00e9rifie ; l’animation de l’interface ne constitue pas une preuve.<\/p>\n Le guide OWASP d’autorisation des transactions<\/a> pr\u00e9conise des contr\u00f4les c\u00f4t\u00e9 serveur et des transitions d’\u00e9tat ma\u00eetris\u00e9es. Appliquez ces principes pour d\u00e9finir quelles requ\u00eates peuvent engager ou modifier une partie.<\/p>\n\n Une interface h\u00e9berg\u00e9e, une diffusion int\u00e9gr\u00e9e ou une connexion API directe peuvent attribuer des responsabilit\u00e9s diff\u00e9rentes \u00e0 l’op\u00e9rateur. Identifiez syst\u00e8me de comptes, service de jeux, registre du portefeuille et responsable du reporting dans la cartographie des responsabilit\u00e9s de la plateforme<\/a>. Convenez de la mani\u00e8re dont expiration de session et restrictions atteignent la d\u00e9cision d’achat.<\/p>\n Le service de jeux doit restituer l’\u00e9tat de r\u00e9f\u00e9rence de la partie et les identifiants n\u00e9cessaires \u00e0 sa reprise. Le portefeuille doit \u00eatre responsable des \u00e9critures financi\u00e8res. L’historique du compte doit pr\u00e9senter clairement achat et r\u00e8glement sans inventer une seconde v\u00e9rit\u00e9 financi\u00e8re. Le support doit pouvoir consulter le parcours entre les trois.<\/p>\n Utilisez le guide des exigences API de loterie<\/a> pour documenter versions, acc\u00e8s, gestion des \u00e9checs et responsabilit\u00e9 de l’adaptateur. Exigez le contrat r\u00e9el du fournisseur et son environnement de test ; un diagramme g\u00e9n\u00e9ral n’est pas une interface impl\u00e9ment\u00e9e.<\/p>\n\n S\u00e9parez perte de connexion et \u00e9chec de la partie. Si la partie a \u00e9t\u00e9 accept\u00e9e et son r\u00e9sultat fix\u00e9, la reconnexion doit retrouver son \u00e9tat selon le mod\u00e8le convenu, pas acheter une autre partie. Rejouer une r\u00e9v\u00e9lation ne doit pas d\u00e9clencher un second d\u00e9bit de mise ou cr\u00e9dit de gain.<\/p>\n Si l’acceptation est incertaine, r\u00e9solvez la r\u00e9f\u00e9rence initiale avant de retenter l’achat. D\u00e9finissez d\u00e9lais d’attente, protection contre les doublons, responsable des nouvelles tentatives et \u00e9tat en attente visible. Un remboursement automatique peut \u00eatre incorrect si la partie initiale \u00e9tait engag\u00e9e ; un deuxi\u00e8me d\u00e9bit automatique peut l’\u00eatre pour la m\u00eame raison.<\/p>\n Utilisez la checklist de rapprochement du portefeuille<\/a> pour relier mises, gains, annulations et \u00e9critures non r\u00e9solues. S\u00e9parez l’alimentation du portefeuille de l’achat d’une partie ; le guide d’int\u00e9gration des paiements<\/a> traite de l’incertitude du paiement externe.<\/p>\n\n Identifiez le mode avant de commencer une partie. D\u00e9monstration, droit promotionnel et achat en argent r\u00e9el peuvent avoir des r\u00e8gles, soldes et rapports diff\u00e9rents. Indiquez au joueur le mode applicable et emp\u00eachez qu’un r\u00e9sultat de d\u00e9monstration apparaisse comme un droit \u00e0 recevoir de l’argent.<\/p>\n Documentez source de financement, \u00e9ligibilit\u00e9, expiration, jeux autoris\u00e9s et traitement des gains pour chaque droit promotionnel. D\u00e9cidez s’il couvre toute la mise ou une partie seulement. Testez la transition lorsqu’il est \u00e9puis\u00e9 ; ne faites pas passer silencieusement la partie suivante en argent r\u00e9el.<\/p>\n Conservez la r\u00e8gle applicable et la version du jeu avec la r\u00e9f\u00e9rence de la partie. Une modification ult\u00e9rieure de promotion ou de contenu ne doit pas r\u00e9\u00e9crire les conditions d’une partie d\u00e9j\u00e0 accept\u00e9e. Confirmez qui configure ces changements et qui approuve leur mise en service.<\/p>\n\n Consignez acceptation, r\u00e9f\u00e9rence du r\u00e9sultat, r\u00e9f\u00e9rences des \u00e9critures, \u00e9tat du r\u00e8glement, cat\u00e9gorie d’erreur et horodatages utiles. Rapprochez par devise, version de jeu et p\u00e9riode op\u00e9rationnelle. Pr\u00e9sentez s\u00e9par\u00e9ment enregistrements en attente et corrig\u00e9s pour ne pas gonfler l’activit\u00e9 termin\u00e9e avec des nouvelles tentatives.<\/p>\n Le guide de journalisation OWASP<\/a> distingue les d\u00e9tails d’\u00e9v\u00e9nements utiles des donn\u00e9es sensibles \u00e0 ne pas journaliser. \u00c9vitez secrets et donn\u00e9es personnelles inutiles dans les traces op\u00e9rationnelles.<\/p>\n Demandez au support de d\u00e9montrer une partie, de l’achat au solde final, avec des donn\u00e9es synth\u00e9tiques. La checklist RNG et pistes d’audit<\/a> ajoute des questions sur configuration, preuves et p\u00e9rim\u00e8tre des essais ind\u00e9pendants. Un certificat concernant une autre version ou un autre composant n’y r\u00e9pond pas.<\/p>\n\n Utilisez des parties synth\u00e9tiques et des r\u00e9sultats attendus explicites. Les exemples ci-dessous sont des exigences de recette propos\u00e9es, pas le comportement de l’API WhiteLotto ni une d\u00e9claration de certification. Ajoutez les cas convenus \u00e0 la checklist UAT et de mise en production<\/a>.<\/p>\nD\u00e9finir le cycle de la partie et la fronti\u00e8re du r\u00e9sultat<\/h2>\n
Attribuer les responsabilit\u00e9s avant de choisir l’int\u00e9gration<\/h2>\n
Reprendre une partie interrompue sans deuxi\u00e8me d\u00e9bit<\/h2>\n
Distinguer d\u00e9monstration, promotion et argent r\u00e9el<\/h2>\n
Rendre l’historique des parties et les traces d’audit exploitables<\/h2>\n
Checklist op\u00e9rateur et sc\u00e9narios de recette<\/h2>\n
\n
Sc\u00e9nario<\/th> \u00c9tat attendu de la partie<\/th> Exigence du registre<\/th> Preuve d’audit<\/th> Condition de r\u00e9ussite<\/th><\/tr><\/thead>\n Connexion perdue apr\u00e8s engagement<\/th> La partie initiale reste identifiable ; son r\u00e9sultat fixe est r\u00e9cup\u00e9rable.<\/td> Une mise accept\u00e9e ; le gain suit le r\u00e9sultat enregistr\u00e9.<\/td> Engagement et reprise partagent la m\u00eame r\u00e9f\u00e9rence.<\/td> Reconnexion et r\u00e9v\u00e9lation ne cr\u00e9ent pas un autre achat.<\/td><\/tr>\n Accus\u00e9 de r\u00e9ception en double<\/th> La m\u00eame partie termin\u00e9e, pas une nouvelle.<\/td> Aucun double d\u00e9bit ou cr\u00e9dit de gain.<\/td> La livraison r\u00e9p\u00e9t\u00e9e est identifiable.<\/td> Le retraitement laisse le r\u00e9sultat financier inchang\u00e9.<\/td><\/tr>\n Mise refus\u00e9e<\/th> Aucune partie payante accept\u00e9e selon la r\u00e8gle de refus convenue.<\/td> Aucune mise conserv\u00e9e pour un achat refus\u00e9.<\/td> Motif de refus et tentative associ\u00e9e consign\u00e9s.<\/td> Le joueur voit le refus, pas un jeu termin\u00e9 trompeur.<\/td><\/tr>\n Cr\u00e9dit du gain en attente<\/th> R\u00e9sultat fixe ; r\u00e8glement visiblement en attente.<\/td> Un seul cr\u00e9dit final apr\u00e8s reprise.<\/td> Obligation initiale et reprise reli\u00e9es.<\/td> Le support explique montant en attente et \u00e9criture finale.<\/td><\/tr>\n Promotion expir\u00e9e avant la partie suivante<\/th> Une nouvelle d\u00e9cision d’\u00e9ligibilit\u00e9 pr\u00e9c\u00e8de l’acceptation.<\/td> Aucune substitution silencieuse par de l’argent r\u00e9el.<\/td> Mode et droit applicable enregistr\u00e9s.<\/td> Le joueur confirme tout nouvel achat payant selon ses r\u00e8gles.<\/td><\/tr>\n<\/tbody><\/table>\n<\/div>\n