Mode test
La même API, des données entièrement séparées et des résultats que vous choisissez.
La sandbox est la même API, avec les mêmes routes et la même validation que le live, et des données entièrement séparées. Aucun argent réel ne circule : 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 court délai remplace un véritable réseau |
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
Rien n'est aléatoire dans la sandbox.
| 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 |
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é dans la sandbox tant que Wajub ne l'a pas activé. Une fois activé, une adresse de dépôt est générée pour chaque scénario, toujours la même, ce qui permet de reproduire un 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, un lien vers une page à quatre boutons, SUCCESS, FAILURE, TIMEOUT et CANCELED. Un clic donne ce résultat au paiement, 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. Une fois le code accepté, le numéro de carte détermine si le paiement réussit ou échoue.