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.
Un environnement sandbox existe (api.sandbox.az54.com, clés sk_test_,
aucun opérateur réel joignable) : c'est là qu'intégrer et tester, avant de
passer en production (api.az54.com, clés sk_live_) où toute requête
sollicite réellement le combiné indiqué et déplace de l'argent réel — voir
Démarrage.
Sur le sandbox, le numéro appelé pilote le résultat — voir Numéros de test. En production, 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, sur le sandbox d'abord.
Numéros de test
Le catalogue des MSISDN qui pilotent un résultat sur le 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 canal nominal de l'issue d'un paiement.
Réconciliation
Rejeu, journal des tentatives, renvoi : rattraper une notification perdue.
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).- Ne concluez rien de l'absence de notification. Le webhook est le chemin nominal ; quand il n'arrive pas, l'issue se lit par clé d'API (Réconciliation). Le reçu public, lui, 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.