Intégration des paiements de loterie : webhooks et remboursements

L’intégration d’une passerelle de paiement de loterie est prête lorsque paiements, écritures du portefeuille et rapports de règlement concordent, même après de nouvelles tentatives, des délais dépassés, des remboursements et des notifications tardives. Un écran de paiement réussi ne prouve pas que l’opérateur a reçu les fonds ni que le bon compte a été crédité […]

L’intégration d’une passerelle de paiement de loterie est prête lorsque paiements, écritures du portefeuille et rapports de règlement concordent, même après de nouvelles tentatives, des délais dépassés, des remboursements et des notifications tardives. Un écran de paiement réussi ne prouve pas que l’opérateur a reçu les fonds ni que le bon compte a été crédité une seule fois.

Ce guide décrit des exigences d’intégration, pas les champs réels de l’API WhiteLotto ni une promesse de compatibilité avec un prestataire nommé. L’admissibilité du prestataire, les produits acceptés et les conditions commerciales doivent être confirmés séparément. Consultez le guide d’architecture des paiements de loterie pour le contexte opérationnel et les coûts.

Séparer les enregistrements du prestataire, du portefeuille et de la finance

Convenez du système responsable de la tentative de paiement, du résultat définitif du prestataire, de l’écriture du portefeuille joueur, de l’instruction de retrait et du rapprochement comptable. Reliez leurs identifiants sans les considérer comme interchangeables. Définissez montants, devise, arrondis et frais à chaque frontière.

Concevoir les webhooks pour les répétitions et les retards

Vérifiez l’origine de l’événement au moyen du mécanisme documenté du prestataire avant de faire confiance à son contenu. Validez compte, paiement, montant et devise référencés. Enregistrez durablement l’événement ou l’opération accepté avant d’envoyer la réponse indiquant à l’émetteur que la livraison a réussi. Traitez les opérations longues par un chemin récupérable.

Ne supposez pas que les événements arrivent une seule fois ou dans l’ordre. Stripe documente la vérification des signatures, les doublons et l’absence d’ordre garanti. Adyen documente ses propres règles d’accusé de réception et de traitement des doublons. Ces références sont propres aux prestataires ; elles ne prouvent pas une intégration WhiteLotto avec l’un ou l’autre.

Choisissez les clés de déduplication et les règles de transition d’état à partir du contrat réel du prestataire. Un nouvel identifiant de livraison peut correspondre au même événement métier. Un événement tardif ne doit pas faire revenir en arrière une opération déjà résolue. Gardez les erreurs visibles dans une file d’exceptions et prévoyez un rejeu contrôlé.

Définir les nouvelles tentatives sûres et les résultats incertains

Supposons que le prestataire réalise une alimentation de compte, mais que la réponse n’arrive jamais à la plateforme. Un nouveau paiement peut débiter à nouveau le joueur. Réutilisez la référence d’opération ou le mécanisme d’idempotence pris en charge et consultez le résultat initial.

La documentation d’idempotence de Stripe illustre le comportement de rejeu d’un prestataire. Ne transposez pas sa durée de conservation ou sa sémantique d’erreurs à un autre. Votre contrat doit préciser la durée de protection, le comportement en cas de conflit de contenu et la récupération après expiration.

Testez la concurrence autant que la répétition : deux traitements peuvent recevoir le même événement simultanément. Une protection qui ne fonctionne que dans une session de navigateur ne suffit pas à protéger le registre partagé du portefeuille.

Rapprocher les mouvements bruts et les écarts

Appariez les opérations du prestataire aux écritures du portefeuille et aux rapports de règlement du prestataire. Expliquez séparément frais, remboursements partiels, montants contestés, écarts de change et décalages temporels. Les dépôts ne sont pas des ventes de billets ; une alimentation réussie ne prouve pas l’acceptation d’un achat de billet ultérieur.

La finance doit pouvoir examiner un montant non apparié avec les références autorisées, les horodatages et l’historique des statuts. Utilisez le cadre d’indicateurs pour présenter valeur et ancienneté non résolues, sans masquer les écarts de signes opposés par compensation.

Liste d’acceptation des paiements

• Tester les alimentations réussies, refusées, annulées et en attente.
• Perdre la première réponse, puis consulter ou rejouer de façon sûre l’opération initiale.
• Envoyer des événements de test dupliqués, concurrents, tardifs et désordonnés.
• Refuser les signatures invalides, devises erronées et références de comptes sans lien.
• Tester remboursements complets et partiels, échecs de retrait et écarts de rapprochement.
• Confirmer l’absence de secrets dans le code du navigateur et les journaux non restreints.

Exécutez ces cas dans les environnements de test autorisés des prestataires avec des données fictives. Les recommandations OWASP de test des paiements constituent une référence utile pour la logique métier et les vérifications temporelles. Consignez les effets financiers réels dans le dossier de réception UAT ; cette liste n’autorise pas les paiements en production.

Questions sur l’intégration des paiements

Une redirection du navigateur doit-elle créditer le portefeuille ?

La décision de crédit nécessite une preuve serveur faisant autorité selon le contrat convenu. Une page de succès du navigateur ne constitue pas cette preuve à elle seule.

L’intégration d’une passerelle garantit-elle l’acceptation d’une activité de loterie ?

Non. Admissibilité, approbation des marchés et produits, et onboarding commercial sont des décisions distinctes du prestataire et des responsables concernés.

Présentez vos moyens de paiement, marchés et exigences de règlement à WhiteLotto. Commencez par l’architecture d’intégration. CONTACT.