Numéros de test

Sur api.sandbox.az54.com, aucun appel réseau n'est fait vers un opérateur. L'issue d'un pay-in ou d'un pay-out est entièrement déterminée par les deux derniers chiffres du numéro appelé. Le reste du numéro garde son sens habituel : son préfixe choisit le pays et l'opérateur — donc le corridor, donc le workflow — exactement comme en production, puisque le sandbox reprend le même catalogue de corridors (Démarrage).

Comment lire un numéro de test

Prenez +2250700000010 :

• +225 (Côte d'Ivoire) + 07 (préfixe Orange Money) → résout le corridor Orange Money CI. Vérifiez ses bornes de montant avec GET /v1/corridors/available.
• 10, les deux derniers chiffres → le scénario « fonds insuffisants » (SIM_INSUFFICIENT_FUNDS), ci-dessous.

Le reste des chiffres n'a aucun effet : +2250712345610 produit exactement le même résultat que +2250700000010.

Catalogue

Trois lectures de cette table :

• Sans *, le statut arrive par le webhook sortant, après un pending initial et le polling interne — le chemin nominal du mobile money, et le seul qui vaut la peine de tester si votre intégration doit refléter la production.

• * (01, 17, 18) court-circuite le polling : le statut terminal est déjà dans la réponse HTTP synchrone de POST /v1/pay-in. Utile pour tester votre gestion d'un refus immédiat, rare en production (réservé aux corridors qui répondent en provider_auth synchrone).

• 16 est le seul scénario sans failureCode ni failureMessage : c'est le numéro qui simule un PSP qui ne dit rien. Voir Causes d'échec — c'est ce qui produit failureCategory: "UNKNOWN" plutôt qu'une catégorie dérivée du code.

• 18 est le seul scénario qui déclenche une bascule de prestataire : le PSP y déclare son propre système indisponible (PROVIDER_UNAVAILABLE), et si le canal a un second prestataire actif, az54 rejoue l'encaissement chez lui — un nouveau prompt part alors sur le même numéro, et la réponse HTTP reste non terminale. Sans second prestataire sur le canal, le pay-in part en failed avec cette catégorie.

20 ne se termine jamais : ni succès ni échec, quel que soit le temps écoulé. C'est le numéro à utiliser pour tester l'épuisement de vos propres tentatives de lecture, ou pour vérifier que rien dans votre intégration ne suppose qu'un paiement finit toujours par se conclure.

Un suffixe hors de ce catalogue (+2250700000099, par exemple) ne renvoie pas une erreur générique : la transaction passe directement en failed, avec un failureCode qui nomme le suffixe fautif — un numéro de test mal formé se comporte comme un refus métier, pas comme une panne.

Un exemple par workflow

Le suffixe pilote toujours l'issue, quel que soit le workflow — seul le préfixe change (Workflows de pay-in) :

• provider_auth — +2250700000000, POST /v1/pay-in normal.
• pre_authorized — +22603000000 (Burkina Faso, Orange), POST /v1/pay-in normal.
• redirect_url — +2250700000000 avec operatorCode: "wave" : le préfixe ne suffit pas à choisir Wave, voir operatorCode.

Le troisième exemple réutilise le numéro Orange du premier : c'est operatorCode qui force le rail Wave, pas le préfixe. La réponse au dispatch reste pending (aucun de ces trois numéros n'a un suffixe synchrone) ; c'est le webhook qui porte ensuite l'authorizationUrl sur le corridor en redirection.

Ce que ce catalogue ne couvre pas

• Un seul PSP répond derrière tous les corridors : il n'y a donc rien à observer par PSP, seulement par suffixe.
• Le pay-out suit la même table, avec les mêmes suffixes — il n'y a pas de catalogue séparé pour les versements.
• Le failureCode, ici comme en production, n'est pas contractuel : ne branchez pas de logique dessus, seul failureCategory l'est (Causes d'échec).