Ipay-Target-Environment: sandbox ; aucune transaction réelle n’est déclenchée. Les requêtes elles-mêmes
ne sont pas répétées ici : reprenez la page « Créer une transaction »
et celle de « Consulter une transaction », et remplacez
seulement les valeurs par celles ci-dessous.
Numéros de test mobile
PourIpay-Payment-Type: mobile en Sandbox, avec country: NE (exemple de la doc), seuls les dix numéros ci-dessous sont acceptés et
simulent chacun un résultat fixe. Tout autre msisdn sur ce type renvoie
400 Bad Request: Incorrect MSISDN, même bien formé : ce n’est pas un simulateur générique
acceptant n’importe quel numéro.
« Erreur », « Fonds insuffisants » et « Refusé » partagent le même statut final
failed : l’API
n’expose pas de sous-catégorie supplémentaire dans le champ status pour distinguer ces trois cas.
Les deux numéros de mise en attente ne restent pas indéfiniment pending : ils passent
automatiquement à succeeded après une résolution différée d’environ 90 secondes — ce n’est ni un
état bloqué à corriger manuellement, ni un résultat aléatoire.
Montant minimum en Sandbox
Pourmobile, le minimum accepté en Sandbox est de 50 XOF, alors que le minimum Live du même
type est de 25 XOF. Un montant compris entre 25 et 49 XOF est donc refusé en Sandbox alors
qu’il serait accepté en Live : n’en déduisez pas le comportement de production, et testez votre
gestion d’erreur avec un montant clairement inférieur aux deux seuils.
Cas à couvrir avant la production
Traitez l’erreur de validation comme une erreur de saisie côté client, pas comme un incident à
relancer automatiquement. La liste complète des codes et messages est dans
Erreurs.