Skip to main content

​
Les huit états

​
Transitions possibles

Deux garanties que ce schéma matérialise.
Une opération réussie ne repasse jamais en échec. Le seul mouvement possible depuis SUCCEEDED est REVERSED, qui est une contre-passation explicite, toujours accompagnée d’une notification operation.reversed. Vous pouvez donc traiter un cashin.succeeded sans craindre qu’il soit silencieusement annulé.
Une opération expirée peut encore aboutir. Un opérateur mobile money confirme parfois plusieurs heures après notre délai d’attente, et dans ce cas les fonds sont bien arrivés. EXPIRED → SUCCEEDED est donc permis : ne considérez pas EXPIRED comme un échec comptable définitif tant que vous n’avez pas rapproché votre relevé.

​
AWAITING_PAYER : le cas à ne pas rater

C’est le seul état qui demande une action de votre part.
Si vous ignorez payerActionUrl, l’encaissement n’aboutira jamais : le client n’a aucun moyen de payer. L’opération passera en EXPIRED au bout de 30 minutes.Ne codez pas en dur la liste des opérateurs à rediriger : testez requiresPayerAction. Le comportement d’un opérateur peut évoluer.

​
Délais d’expiration

Le champ expiresAt donne l’échéance exacte de chaque opération.

​
Suivre l’historique

Utile lors d’un litige : vous voyez le parcours complet, pas seulement l’état final.

​
La consultation reste la source de vérité

Ne faites jamais dépendre un état critique de la seule arrivée d’une notification. Les notifications peuvent être retardées, et votre endpoint peut être momentanément indisponible.GET /operations/{reference} donne toujours l’état réel. Prévoyez une tâche de rattrapage qui interroge les opérations restées non définitives au-delà de leur expiresAt.