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.Documentation Index
Fetch the complete documentation index at: https://developers.ligdicash.com/llms.txt
Use this file to discover all available pages before exploring further.
Les trois statuts
| Statut | Signification |
|---|---|
pending | Transaction créée, en attente d’une issue définitive |
completed | Paiement confirmé avec succès — état final |
notcompleted | Paiement échoué ou annulé — état final |
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.
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 à votrecallback_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.
Consultez Sécuriser le callback pour le pattern de re-vérification complet.
Pages associées
- Sécuriser le callback — pattern de re-vérification avec
confirm - Polling vs callback — quand utiliser l’un ou l’autre
- Codes de réponse et statuts
