Tester

Une clé de test ne déplace aucun argent réel — mais presque tout le reste est vrai.

Les clés de test

Vos clés existent en deux familles : sk_live_… et sk_test_…. La clé utilisée marque l'opération pour toute sa vie ; rien ne fait passer une opération d'une famille à l'autre.

Avec une clé de test :

• aucun fournisseur n'est jamais appelé. Une simulation répond à sa place, toujours — une campagne de test ne peut pas atteindre un vrai rail, ni le perturber.
• le grand livre, les règlements et les notifications transactionnelles sont exclus. Aucun mouvement comptable, aucun décompte de règlement, aucun SMS ni e-mail au payeur.
• tout le reste est réel : la chaîne d'acceptation, vos webhooks, vos journaux de développeur, vos lignes de reporting, et l'intégralité des contrôles de risque.

Montants magiques

Les deux derniers chiffres du montant choisissent l'issue. C'est le seul moyen de répéter les chemins d'échec, qu'un rail en bon état ne produit jamais.

Le montant finit par	Ce qui se passe
99	Refusé à la soumission, définitivement. La classe « numéro invalide » — ne réessayez pas
98	Refusé à la soumission, temporairement. La classe « panne de rail » — réessayer a du sens
97	Accepté, puis échoué. pending d'abord, failed ensuite
n'importe quoi d'autre	Accepté, puis success

Cela vaut pour les encaissements, les versements, les remboursements et les annulations.

Le cas 97 est celui qu'il faut vraiment répéter

C'est la séquence que les intégrations manquent : votre webhook reçoit pending, vous marquez la commande « en attente de paiement », puis failed arrive et doit défaire ce que pending a fait. Sans un moyen de la provoquer, la première exécution de ce chemin a lieu en production.

Un montant qui a encodé un échec échoue de bout en bout : une opération ne peut pas à la fois refuser et réussir, même après plusieurs lectures.

Identités de test

Les contrôles de conformité se répètent de la même manière, avec des identités magiques. Elles ne correspondent qu'aux opérations de test.

Identité	Ce qu'elle répète	Ce que vous devez voir
+221700000001 — « Test Sanctionne Fort »	Correspondance forte sur une liste de sanctions	Le paiement est refusé.
« Test Sanctionne Nom Seul » (nom seul, aucun numéro)	Correspondance sur le nom uniquement	Accepté, puis retenu pour examen — voir ci-dessous
+221700000003 — « Test Personne Politiquement Exposee »	Personne politiquement exposée	Examen renforcé, pas un refus
+221700000004 — « Test Identite Mineure »	Identité connue comme mineure	Refusé sur un corridor restreint (jeux, paris), accepté ailleurs

Jeu d'identités en vigueur : fixture-2026-09-13-1. Il est identique dans tous les environnements, et il change par version — un test écrit contre un jeu nommé reste reproductible.

Un nom seul n'est jamais un refus

La deuxième ligne du tableau surprend, et c'est volontaire : une correspondance sur le seul nom n'arrête pas un paiement. Les patronymes se partagent ; refuser sur un nom reviendrait à refuser beaucoup de monde pour la bonne orthographe. Le paiement est donc accepté et retenu pour examen, et votre intégration doit traiter ce cas comme une attente, pas comme un échec.

Un refus demande un identifiant fort — un numéro, un document.

⚠️ Ces identités ne sont pas de vraies personnes, et elles ne correspondent jamais à un paiement en production. Les utiliser avec une clé sk_live_ ne produit rien : ce sont des identités de répétition, et c'est tout ce qu'elles sont.

Ce que vous pouvez répéter

• risk.status à review puis à held, sur le webhook comme en lecture ;
• les événements payment.held et payment.released ;
• un dossier de conformité ouvert dans la voie de test : visible pour vous, et il n'atteint jamais nos équipes de conformité ni aucun décompte réglementaire.

Ce qu'un test ne montre pas

Trois limites, dites franchement plutôt que découvertes plus tard :

1. Aucun mouvement comptable. Le grand livre est hors du périmètre de test, donc rien de ce qui concerne un solde disponible, une retenue ou une libération de fonds ne se vérifie ici.
2. Le temps n'est pas le temps de production. La simulation n'a pas de payeur : la confirmation vient d'un balayage à sa propre cadence, pas de quelques secondes après un code USSD. Testez la transition, jamais l'horloge.
3. Les notifications transactionnelles ne partent pas. Ni au payeur, ni à vous.

À ne pas faire

• Ne dérivez pas vos délais de production de vos délais de test. Voir le point 2.
• Ne traitez pas pending comme un échec, en test comme en production.
• Ne recopiez jamais une identité de test dans vos données de production. Elles n'y correspondent à rien, et une donnée de répétition dans un dossier réel est une piste fausse pour quiconque le lira ensuite.