Cycle de vie du billet de loterie : acceptation, règlement et reprise
Un billet de loterie ne se limite pas à une ligne dans l’historique d’achat du joueur. Il relie un produit, un tirage, une opération financière et un droit au résultat. Lorsque ces enregistrements divergent, le support ne peut pas expliquer si l’achat a abouti, la finance ne peut pas rapprocher le solde et l’opérateur risque […]
Un billet de loterie ne se limite pas à une ligne dans l’historique d’achat du joueur. Il relie un produit, un tirage, une opération financière et un droit au résultat. Lorsque ces enregistrements divergent, le support ne peut pas expliquer si l’achat a abouti, la finance ne peut pas rapprocher le solde et l’opérateur risque de régler deux fois la même transaction.
Ce guide décrit le cycle de vie d’un billet, de la sélection au règlement. Utilisez-le pour définir les exigences d’une plateforme de loterie et transformer une démonstration commerciale en tests de recette concrets.
Définir le billet avant de définir ses états
Documentez le jeu, l’identifiant du tirage, la sélection, la mise, la devise, le canal de vente et la version des règles applicables. Le billet doit disposer d’un identifiant stable relié à l’opération financière. Distinguez un billet regroupant plusieurs grilles de chaque participation individuelle ; sinon, un achat partiellement rejeté devient difficile à représenter.
Le système de référence doit également préciser la clôture des ventes, l’horloge faisant autorité et l’horodatage qui détermine l’acceptation. Une demande reçue avant la clôture n’est pas nécessairement une participation acceptée. Cette distinction appartient à l’interface et aux procédures opérationnelles, pas seulement à la documentation technique.
Construire une matrice des états et des flux financiers
Les libellés doivent expliquer ce qui s’est passé, qui peut agir ensuite et ce qu’il est advenu des fonds. L’exemple suivant décrit des exigences, pas une nomenclature imposée.
| État | Vue du joueur | Traitement financier | Preuve requise |
|---|---|---|---|
| Brouillon | Sélection non achetée | Aucun débit | Sélection et prix indiqué |
| Soumis | Confirmation en attente | Réservation si l’architecture en prévoit une | ID de demande et heure de soumission |
| Accepté | Participation au tirage indiqué | Débit d’achat enregistré | ID du billet, tirage et heure d’acceptation |
| Rejeté | Participation non acceptée | Libérer la réservation ; contrepasser tout débit associé | Motif et ajustement financier lié |
| Réglé | Résultat et gain disponibles | Crédit du gain, le cas échéant | Version du résultat et ID du règlement |
| Annulé | Participation devenue invalide | Remboursement selon les règles applicables | Autorisation, motif et référence du remboursement |
Ne remplacez pas l’achat par le remboursement. Conservez l’opération d’origine et un ajustement lié. L’architecture des paiements doit rendre cette relation visible lors du rapprochement.
Scénario : l’achat expire près de la clôture du tirage
Un joueur soumet un achat, le serveur l’accepte, mais la réponse de confirmation est perdue. Le joueur réessaie après la clôture. Une architecture sûre doit répondre explicitement à chaque étape :
- La nouvelle tentative utilise la même clé d’opération et retrouve le résultat existant sans créer un autre billet.
- Le billet accepté conserve son tirage et son heure d’acceptation d’origine ; la tentative ne le transfère pas vers un tirage ultérieur.
- Le portefeuille affiche un seul débit d’achat et toute réservation temporaire est résolue.
- L’interface affiche l’issue finale, tandis que le support peut consulter la séquence des événements sans la modifier.
Demandez au fournisseur de démontrer cette séquence, y compris le cas d’une demande rejetée. Une capture d’écran d’un achat réussi ne teste pas la reprise.
Tests de recette à demander par l’opérateur
- Une demande répétée ne crée ni participations ni débits en double.
- Un achat de plusieurs grilles partiellement rejeté présente un prix et une issue explicables.
- L’annulation d’un tirage suit le remboursement approuvé sans supprimer l’historique.
- Un résultat corrigé produit un ajustement de règlement traçable, pas un remplacement invisible.
- Les canaux web, mobile et physiques appliquent les mêmes règles d’acceptation et affichent des états cohérents.
Ajoutez les permissions, responsables d’escalade et durées de conservation des preuves à la checklist de sécurité et de service. Reliez les corrections de résultats à l’intégrité des tirages et aux pistes d’audit.
Préciser les preuves d’intégration et de transfert
Documentez les identifiants de demandes, consultations d’état, livraisons d’événements, nouvelles tentatives et exports de rapprochement dans les exigences de l’API de loterie. Définissez comment trouver les demandes non résolues et qui peut les traiter. Lors d’une migration de plateforme, conservez les identifiants de billets, références historiques de tirages et obligations non réglées ; migrer uniquement les soldes ne suffit pas.
Questions sur le cycle de vie du billet
Confirmer le paiement signifie-t-il accepter le billet ?
Pas nécessairement. Le paiement et l’acceptation sont deux événements distincts, sauf si l’architecture documentée les réunit dans une opération contrôlée.
Toutes les plateformes doivent-elles utiliser ces noms ?
Non. Les noms peuvent varier, mais acceptation, rejet, règlement et annulation doivent avoir un sens sans ambiguïté.
Un administrateur peut-il modifier un billet ?
Définissez les actions autorisées, approbations et preuves d’audit. Une modification ne doit jamais masquer l’enregistrement accepté d’origine.
Que doit inclure une démonstration technique ?
Un achat normal, une nouvelle tentative, un rejet à la clôture, une annulation et une correction de résultat, reliés aux écritures financières.
Discuter de votre parcours de billet
Préparez vos types de jeux, canaux, règles de clôture et périmètres d’intégration actuels. Prenez CONTACT avec WhiteLotto pour discuter du cycle de vie requis et des preuves à demander pendant une démonstration.