Pourquoi Mobile Money est incontournable en Afrique
En Afrique centrale et de l'Ouest, la carte bancaire reste minoritaire. Ce qui domine, c'est le Mobile Money : MTN MoMo, Orange Money, et leurs équivalents. Pour une application qui veut encaisser des paiements — boutique en ligne, fintech, app de collecte, SaaS — intégrer Mobile Money n'est pas une option, c'est la condition pour avoir des clients qui paient.
Mais entre « ajouter un bouton payer » et « avoir un système de paiement fiable en production », il y a un monde. Voici ce qu'il faut vraiment comprendre.
Les deux acteurs principaux
- MTN Mobile Money (MoMo) expose une API (MTN MoMo Open API) avec deux produits clés : Collection (encaisser de l'argent) et Disbursement (envoyer de l'argent). L'accès se fait via un compte développeur, une clé d'API et un jeton d'accès (OAuth).
- Orange Money propose son API de paiement web : votre serveur initie une demande de paiement, l'utilisateur confirme côté Orange, et vous êtes notifié du résultat.
Dans les deux cas, le principe est le même : votre backend dialogue avec l'opérateur, jamais directement votre app mobile. Les secrets (clés, jetons) ne doivent jamais vivre côté client.
Comment fonctionne un paiement Mobile Money
Le flux typique d'un encaissement :
- L'utilisateur saisit son numéro et valide le montant dans votre app.
- Votre backend appelle l'API de l'opérateur pour initier la transaction (
requestToPaycôté MoMo, demande de paiement côté Orange). - L'opérateur envoie une invite USSD/push sur le téléphone de l'utilisateur, qui saisit son code secret pour confirmer.
- La transaction passe par un état « en attente » (pending), puis « réussie » ou « échouée ».
- Votre backend apprend le résultat — soit en interrogeant le statut (polling), soit via un webhook/callback envoyé par l'opérateur.
Le point crucial : l'étape 3 est asynchrone et hors de votre contrôle. L'utilisateur peut mettre 2 secondes ou 2 minutes, ou ne jamais confirmer.
Les vrais défis techniques (là où ça casse)
1. Les confirmations asynchrones
Vous n'obtenez pas le résultat instantanément. Deux stratégies :
- Polling : interroger périodiquement le statut de la transaction. Simple, mais coûteux et lent.
- Webhook : l'opérateur appelle votre URL quand l'état change. Plus propre, mais il faut une URL publique, sécurisée, et idempotente (le même événement peut arriver plusieurs fois).
En pratique : webhook plus un polling de secours pour les cas où la notification se perd.
2. Les états intermédiaires et les échecs
Une transaction n'est pas binaire. Il faut gérer explicitement : pending, successful, failed, timeout, solde insuffisant, numéro invalide, utilisateur qui refuse. Chaque cas doit avoir un comportement clair dans votre app — sinon vous livrez un produit qui « marche sur le bonheur ».
3. L'idempotence (éviter le double paiement)
Si un utilisateur clique deux fois, ou si une requête est rejouée, vous ne devez jamais encaisser deux fois. La solution : une clé d'idempotence (un identifiant unique de transaction généré côté serveur) et une vérification avant chaque initiation.
4. La réconciliation
À la fin de la journée, ce que dit votre base de données doit correspondre exactement à ce que dit l'opérateur. Un job de réconciliation qui compare vos transactions à celles de l'API évite les écarts silencieux — et les mauvaises surprises comptables.
5. La sécurité
- Secrets côté serveur uniquement, jamais dans l'app.
- Validation de l'authenticité des webhooks (signature / IP de l'opérateur).
- Journalisation de chaque transaction pour l'audit.
Checklist d'une intégration prête pour la production
- Backend qui initie les paiements (jamais le client)
- Gestion explicite de tous les états (pending, success, failed, timeout)
- Webhook idempotent + polling de secours
- Clé d'idempotence pour éviter les doublons
- Job de réconciliation quotidien
- Validation des webhooks et secrets côté serveur
- Journal d'audit de chaque transaction
- Tests en environnement sandbox avant la prod
Par où commencer
Une intégration Mobile Money propre — un opérateur, encaissement de bout en bout, gestion des erreurs et webhooks — se met en place en 2 à 3 semaines selon la complexité de votre produit. Le plus long n'est pas l'« happy path » : c'est de rendre le système fiable face aux échecs.
Vous avez un projet ?
J'intègre Mobile Money (MTN MoMo, Orange Money) dans des apps web et mobiles, de bout en bout, avec gestion des erreurs et réconciliation. Si vous construisez un produit qui doit encaisser des paiements en Afrique, parlons-en — le premier échange est gratuit.