> ## 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.

# Cycle de vie d'une transaction

> Les trois statuts d'une transaction LigdiCash — pending, completed, notcompleted — et pourquoi une transaction peut rester pending indéfiniment.

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

| 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.

<Warning>
  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.
</Warning>

## `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).

```mermaid theme={null}
stateDiagram-v2
    [*] --> pending : Création de la transaction
    pending --> pending : Tentatives échouées, réclamations en cours
    pending --> completed : Paiement confirmé (état final)
    pending --> notcompleted : Annulation confirmée (état final, rare)
```

## 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.

<Warning>
  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.
</Warning>

Consultez [Sécuriser le callback](/api-paiement/callback/securisation) pour le pattern de re-vérification complet.

## Pages associées

* [Sécuriser le callback](/api-paiement/callback/securisation) — pattern de re-vérification avec `confirm`
* [Polling vs callback](/api-paiement/verification-statut/polling-vs-callback) — quand utiliser l'un ou l'autre
* [Codes de réponse et statuts](/concepts/codes-reponse-statuts)