Le verdict en trois phrases
Avant toute mise en production, un checkout mobile money doit passer par une sandbox : c'est là que se jouent 70 % des futurs bugs. La règle d'or : ne jamais mélanger clés test et clés live, et disposer d'un environnement staging séparé — il réduit les incidents de production de 60 %. Testez explicitement les échecs (insufficient_funds, invalid_pin, transaction_declined), pas seulement le chemin heureux.
Clés test vs clés live : ne jamais confondre
Chaque environnement a sa paire de clés. Les clés test n'engagent aucun argent réel ; les clés live si. Un préfixe distingue les deux — vérifiez-le dans votre config avant chaque déploiement.
| Élément | Environnement test | Environnement live |
|---|---|---|
| Clé API | test_... | live_... |
| Argent réel | Non | Oui |
| Webhooks | vers URL staging | vers URL prod |
| Numéros | numéros de test | numéros réels |
| Usage | dev, CI, QA | clients |
Les codes d'erreur à simuler absolument
Un checkout robuste gère chaque cas d'échec avec un message clair. Simulez-les en sandbox avant la prod : c'est le meilleur moyen d'éviter les paniers abandonnés silencieux.
| Code d'erreur | Signification | Message client conseillé |
|---|---|---|
insufficient_funds | Solde insuffisant | « Solde insuffisant, réessayez » |
invalid_pin | Code PIN erroné | « PIN incorrect » |
transaction_declined | Refus opérateur | « Paiement refusé » |
timeout | Session expirée | « Délai dépassé, réessayez » |
limit_exceeded | Plafond dépassé | « Montant trop élevé » |
invalid_number | Numéro invalide | « Vérifiez votre numéro » |
La checklist avant go-live
Un passage en production réussi suit une liste fixe. Cochez chaque ligne avant d'ouvrir les vannes aux vrais clients.
| Vérification | Fait ? |
|---|---|
| Webhook signé et vérifié | ☐ |
| Réponse HTTP 200 < 2 s | ☐ |
| Table de déduplication active | ☐ |
| Tous les codes d'erreur testés | ☐ |
| Bascule clés test → live | ☐ |
| Monitoring et alertes en place | ☐ |
Mini cas pratique
Besoin d'un site web professionnel ?
Kolonell crée des sites web qui attirent des clients, optimisés pour le marché sénégalais. Devis gratuit en 2 minutes.
Cheikh, développeur d'une boutique de streetwear à Thiès, a lancé un checkout Wave sans staging séparé. Sur son premier mois, 70 commandes sur 900 ont buggé (webhook mal géré), soit 7,8 %, à 16 000 FCFA de panier moyen = 1 120 000 FCFA de ventes en incident. En ajoutant un environnement staging et en testant les six codes d'erreur, il ramène le taux d'incident à ~3 %, récupérant environ 672 000 FCFA le mois suivant. Le staging a coûté 1 jour de mise en place.
FAQ
Pourquoi tant de bugs viennent-ils des webhooks ?
Parce qu'ils sont asynchrones et difficiles à reproduire à la main : environ 70 % des incidents de production paiement proviennent de webhooks non testés. Les simuler en sandbox est la seule vraie parade.
Peut-on tester sans argent réel ?
Oui : les clés test et les numéros de test permettent de dérouler tout le tunnel — succès, échec, timeout — sans mouvement d'argent. C'est exactement l'objet de la sandbox.
Un environnement staging est-il vraiment nécessaire ?
Oui. Un staging séparé de la prod réduit les incidents d'environ 60 %, car il attrape les erreurs de config (mauvaises clés, mauvaise URL webhook) avant qu'elles n'atteignent les clients.
Quels codes d'erreur faut-il simuler en priorité ?
Au minimum insufficient_funds, invalid_pin, transaction_declined et timeout. Ce sont les plus fréquents en conditions réelles et ceux qui génèrent le plus de paniers abandonnés s'ils sont mal gérés.
Discutons de votre projet. Nous mettons en place sandbox, staging et checklist go-live pour un checkout mobile money sans surprise. WhatsApp +221 77 596 93 33.
Mohamed Bah
Fondateur, Kolonell
Passionné par le digital et l'entrepreneuriat en Afrique, Mohamed accompagne les entreprises sénégalaises dans leur transformation digitale depuis 2020. Fondateur de Kolonell, il croit que chaque PME mérite une présence en ligne professionnelle et accessible.
