Passer au contenu principal
Une transaction LigdiCash ne passe pas directement de « créée » à « payée ». Elle traverse des états que votre système doit savoir interpréter. Le comportement est différent de ce que l’on trouve habituellement dans d’autres passerelles de paiement — il est important de bien le comprendre avant de concevoir votre intégration.

​
Les trois statuts

​
Ce que pending signifie vraiment

pending est l’état par défaut de toute transaction à la création. C’est aussi l’état dans lequel la plupart des transactions restent le plus longtemps — et parfois indéfiniment. Plusieurs tentatives de paiement échouées sur une même transaction ne font pas passer celle-ci à notcompleted. Le client peut saisir un OTP incorrect plusieurs fois : la transaction reste pending. Il n’existe pas de délai d’expiration côté LigdiCash. Une transaction peut rester à pending des jours après sa création, pour une raison simple : un client peut déposer une réclamation auprès de son opérateur mobile money, et l’opérateur peut valider ou annuler la transaction plusieurs jours plus tard. LigdiCash attend l’issue définitive avant de mettre à jour le statut.
Ne considérez jamais qu’une transaction pending est perdue ou expirée. Ne la recréez pas automatiquement après un délai. Attendez le callback ou interrogez confirm avant de prendre une décision.

​
completed et notcompleted sont des états finaux

Une fois qu’une transaction atteint completed ou notcompleted, son statut ne changera plus. notcompleted est rare — il indique qu’une issue définitive négative a été confirmée (annulation opérateur, rejet définitif).

​
Comment connaître le statut

Deux mécanismes permettent de suivre le statut d’une transaction : Le callback — LigdiCash envoie une notification à votre callback_url quand le statut change. C’est le mécanisme principal. L’endpoint confirm — vous pouvez interroger LigdiCash à tout moment avec le token stocké à la création pour obtenir le statut courant.
Ne mettez jamais à jour le statut d’une commande sur la seule base du payload reçu dans le callback. Appelez toujours confirm avec le token stocké à la création pour valider. N’importe qui connaissant votre URL de callback pourrait envoyer un faux payload.
Consultez Sécuriser le callback pour le pattern de re-vérification complet.

​
Pages associées