Documentation API az54
Encaisser et verser en mobile money via l'API az54.
Cette documentation s'adresse aux intégrateurs qui appellent l'API az54 avec une clé d'API d'organisation.
Il n'existe pas de sandbox : sk_test_ et sk_live_ sont fonctionnellement
identiques, toute requête atteint les vrais opérateurs et déplace de l'argent
réel. Les exemples de cette documentation ne contiennent donc volontairement
aucun numéro de téléphone réel.
Un premier appel se fait au montant minimum du corridor, vers un numéro dont vous possédez le combiné.
Par où commencer
Démarrage
Le premier pay-in, et l'absence de sandbox.
Authentification
Le header, la portée d'une clé, la marche à suivre en cas de fuite.
Montants et devises
Unité majeure, décimales admises, frais.
Workflows de pay-in
OTP, redirection, et pourquoi le 422 est le chemin nominal.
Webhook sortant
Le seul canal qui vous dit ce qu'est devenu un paiement.
Les trois pièges qui coûtent de l'argent
- Un
502ou un timeout ne veut pas dire « échoué ». L'issue est indéterminée : rejouez la même requête, avec le mêmeorderId(Idempotence). cancelledest un échec, au même titre quefailed(Statuts).- Sans webhook, vous ne saurez jamais si un paiement a abouti. Le reçu public n'est pas une alternative (Reçu public).
La référence des endpoints est générée depuis les schémas que le serveur applique au runtime : elle ne peut pas diverger du contrat sans faire échouer la CI.