Mode test
La même API, des données entièrement séparées et des résultats que vous choisissez.
La sandbox n'est ni un produit distinct ni un faux serveur. Elle utilise la même API, les mêmes routes et la même validation, avec des données entièrement séparées du live. Seule l'origine de l'argent change : aucun opérateur n'est contacté et le résultat dépend du numéro, de la carte ou du compte de test utilisé.
Sélection de l'environnement
L'environnement dépend de la clé. Il n'existe aucun paramètre, en-tête ou option pour le sélectionner.
| Préfixe | Environnement |
|---|---|
pk_test., sk_test., rk_test. | Sandbox |
pk., sk., rk. | Live |
Une clé de sandbox ne peut pas lire les données live, et inversement : la sandbox et le live sont entièrement séparés. C'est aussi pourquoi un paiement créé dans la sandbox n'apparaît jamais dans votre Konsole live et qu'aucun filtre n'est nécessaire.
Vous ne pouvez pas supprimer les données de la sandbox par erreur
Aucun bouton ni endpoint ne permet d'effacer un environnement. Il n'existe toutefois aucun chemin de migration : rien de ce que vous créez dans la sandbox, qu'il s'agisse de clients, de bénéficiaires ou d'endpoints, ne vous suit lors du passage en live. Recréez ces éléments volontairement.
Ce qui est réel
| Réel dans la sandbox | Signification |
|---|---|
| Validation | Les mêmes règles et les mêmes messages 422 |
| Plafonds | Les montants minimaux et maximaux sont appliqués de la même manière |
| Événements et webhooks | De vrais événements, de vraies signatures et de vraies nouvelles tentatives |
| Idempotence | Le même comportement lorsqu'une clé est réutilisée |
| Limites de requêtes | Les mêmes plafonds, comptés à part du live : un test de charge en sandbox ne consomme pas votre minute live |
| Solde | Un solde de sandbox distinct, crédité par les paiements de sandbox |
| Frais de plateforme | 2 % sont prélevés sur les paiements et transferts réussis, ce qui produit fee.charged |
Le dernier point surprend souvent : un paiement de sandbox de 5 000 XAF crédite moins de 5 000 XAF sur votre solde de sandbox, exactement comme en mode live.
Ce qui est simulé
| Élément simulé | Méthode |
|---|---|
| L'opérateur | Le numéro de test détermine le résultat, aucun appel n'est effectué |
| Le réseau de cartes | La carte de test détermine le résultat |
| 3D Secure | Le Checkout hébergé demande un code envoyé par e-mail, puis la carte de test détermine le résultat |
| La banque | Les deux derniers chiffres du compte déterminent le résultat |
| Les cryptomonnaies | Une adresse de dépôt est générée par résultat ; envoyer l'une d'elles comme wallet_address décide du résultat |
| Le délai | Un délai fixe remplace un véritable réseau |
Les délais sont courts et fixes, ce qui rend possible une suite de tests automatisés.
| Opération | Délai avant le statut final |
|---|---|
| Paiement | 3 secondes |
| Remboursement | 2 secondes |
| Transfert | 2 secondes |
Asynchrone, pas instantané
Un paiement de sandbox possède encore le statut pending au retour de l'appel. Un test qui vérifie immédiatement le statut succeeded après sa création échouera. Attendez le webhook ou utilisez le polling jusqu'à l'obtention d'un statut final.
Des résultats déterministes
Ce point est essentiel : rien n'est aléatoire dans la sandbox, à une exception près.
| Objet | Élément qui détermine le résultat |
|---|---|
| Paiement Mobile Money | Le suffixe du numéro du payeur |
| Paiement par carte | Le numéro exact de la carte |
| Paiement bancaire | Les deux derniers chiffres du compte |
| Paiement en cryptomonnaie | L'adresse de crypto.deposit.scenarios envoyée comme wallet_address (aucune : réussite) |
| Remboursement | La carte ou le téléphone du paiement d'origine |
| Transfert | Le numéro ou le compte de test du bénéficiaire |
L'exception concerne le remboursement d'un paiement sans moyen de paiement associé, qui possède 70 % de chances de réussir. En pratique, cela se produit uniquement pour les paiements créés sans payeur, ce qui ne correspond pas à un parcours que vous déployez.
Les transferts sont également déterministes
Un transfert de sandbox vers un bénéficiaire Mobile Money exige un numéro de test reconnu. Tout autre numéro est refusé avec une erreur 422 qui liste les valeurs valides. Aucune probabilité n'intervient.
Le solde de la sandbox
Les payouts nécessitent de l'argent. Les paiements de sandbox créditent un solde de sandbox et les transferts le débitent. L'ordre de vos tests est donc important : créez et terminez un paiement avant de tester un payout. Sinon, le transfert échoue pour cause de fonds insuffisants, exactement comme en production.
Un transfert échoué restitue le montant au solde. Les frais de plateforme de 2 % ne sont pas restitués, ce qui reproduit le comportement du mode live.
Les cryptomonnaies sont désactivées par défaut
Le canal des cryptomonnaies est désactivé par défaut dans la sandbox, et il s'active pour toute la plateforme sandbox, pas par compte. Une fois activé, une adresse de dépôt et une URI de paiement sont générées pour chaque scénario. Elles restent valides pendant 30 minutes. L'adresse elle-même est déterministe, ce qui permet de reproduire deux fois le même scénario.
Personne n'envoie de fonds en sandbox : la réponse à POST /payments/{id} sur un canal de cryptomonnaie contient donc aussi un simulator_url. C'est un lien signé, valide 30 minutes, vers une page à quatre boutons, SUCCESS, FAILURE, TIMEOUT et CANCELED. Un clic met ce résultat en file, et le paiement avance ensuite comme après un vrai dépôt, webhooks compris. Ce champ n'existe jamais en live.
3D Secure demande un code par e-mail
Une carte de test 3D Secure des scénarios répond 202 avec action: "confirm_3ds". Sur le Checkout hébergé, le payeur doit alors saisir un code à six chiffres, que Wajub envoie par e-mail à l'adresse du client et au propriétaire du compte, pour que la vérification reste possible quand le client de test a une adresse fictive. Le code est valable 10 minutes et accepte 3 essais. Une fois le code accepté, le numéro de carte détermine si le paiement réussit ou échoue.