Mobile money et paiements en ligne : intégrer les paiements dans une application en Afrique de l'Ouest

En Afrique de l'Ouest, une application qui encaisse de l'argent doit presque toujours accepter le mobile money. Pour une grande partie des utilisateurs, c'est le moyen de paiement du quotidien, devant la carte bancaire. Intégrer ce mode de paiement n'est pourtant pas aussi simple qu'ajouter un bouton « Payer » : les parcours sont différents de ceux d'une carte, les confirmations arrivent de manière asynchrone, et la fiabilité dépend de plusieurs acteurs.

Cet article rassemble les principes que nous appliquons chez KODEX CracLabs lorsque nous intégrons des paiements dans une application web ou mobile.

Comprendre le parcours d'un paiement mobile money

Un paiement par carte suit généralement un parcours synchrone : l'utilisateur saisit ses informations, la banque répond, la page affiche le résultat. Le mobile money fonctionne différemment. Dans un parcours typique :

1. l'application initie une demande de paiement auprès de l'opérateur ou d'un agrégateur ;
2. l'utilisateur reçoit une demande de confirmation sur son téléphone et valide avec son code secret ;
3. l'opérateur traite la transaction ;
4. le résultat est transmis à votre serveur, souvent par une notification (webhook), parfois plusieurs secondes ou minutes plus tard.

Conséquence directe : votre application doit savoir gérer l'attente. Une commande ne passe pas de « en cours » à « payée » au moment du clic, mais au moment où la confirmation arrive.

Agrégateur ou intégration directe ?

Deux approches existent pour accepter le mobile money.

Passer par un agrégateur de paiement

Un agrégateur propose une seule API pour plusieurs moyens de paiement : différents opérateurs mobile money, souvent les cartes bancaires, parfois plusieurs pays. C'est l'option la plus rapide à mettre en œuvre et la plus simple à maintenir. En contrepartie, l'agrégateur prélève une commission et vous dépendez de sa disponibilité et de ses conditions.

Intégrer directement les opérateurs

L'intégration directe avec chaque opérateur peut réduire les intermédiaires, mais elle implique des démarches contractuelles avec chacun, une API différente à maintenir par opérateur et davantage de tests. Elle se justifie surtout pour des volumes importants ou des besoins très spécifiques.

Pour la plupart des PME, startups et organisations, nous recommandons de commencer avec un agrégateur reconnu, en isolant son intégration dans le code de manière à pouvoir en changer ou en ajouter un second si nécessaire.

Les critères de choix d'un prestataire

• les opérateurs et pays couverts, au regard de votre clientèle réelle ;
• la qualité de la documentation et l'existence d'un environnement de test (sandbox) ;
• la gestion des notifications et la possibilité de vérifier le statut d'une transaction ;
• les délais et modalités de reversement des fonds ;
• les frais, et la possibilité de les répercuter ou non sur le client ;
• la réactivité du support technique.

Une architecture robuste : les principes clés

Le serveur est la seule source de vérité

Ne considérez jamais un paiement comme validé parce que l'application mobile ou la page web l'affiche. Seul votre serveur, après confirmation par le prestataire, peut changer le statut d'une commande. Les clés d'API restent sur le serveur, jamais dans le code de l'application mobile ou du navigateur.

Vérifier chaque notification

Une notification de paiement peut être falsifiée. Vérifiez sa signature lorsque le prestataire en fournit une, et, par précaution, interrogez l'API du prestataire pour confirmer le statut et le montant avant de valider la commande.

Rendre les traitements idempotents

Une même notification peut arriver plusieurs fois. Votre code doit le supporter : recevoir deux fois la confirmation d'un paiement ne doit jamais livrer deux fois la commande ni créditer deux fois un compte. Un identifiant unique par transaction, enregistré en base, suffit généralement à garantir ce comportement.

Prévoir les statuts intermédiaires et les relances

Une transaction peut être en attente, réussie, échouée, expirée ou annulée. Modélisez explicitement ces statuts. Si aucune notification n'arrive, une tâche planifiée doit interroger le prestataire pour récupérer le statut réel, plutôt que de laisser des commandes bloquées indéfiniment.

Un bon système de paiement ne se juge pas sur le parcours qui fonctionne, mais sur la manière dont il gère les parcours qui échouent.

L'expérience utilisateur du paiement

Le paiement est le moment où l'utilisateur hésite le plus. Quelques règles réduisent les abandons :

• Annoncer le parcours : indiquez clairement que l'utilisateur va recevoir une demande de confirmation sur son téléphone.
• Afficher un état d'attente explicite, avec la possibilité de revenir plus tard sans perdre sa commande.
• Pré-remplir le numéro lorsque l'utilisateur l'a déjà fourni, et valider son format avant l'envoi.
• Afficher le montant total, frais compris, avant la confirmation.
• Envoyer un reçu (SMS, e-mail ou message) une fois le paiement confirmé.
• Proposer une alternative en cas d'échec : autre opérateur, carte, ou nouvel essai.

Le rapprochement et le suivi financier

Encaisser n'est que la moitié du travail. Il faut ensuite pouvoir rapprocher chaque transaction de votre système avec les relevés du prestataire, suivre les reversements et traiter les remboursements. Prévoyez dès le départ :

• un journal complet des transactions, avec les références du prestataire ;
• un écran d'administration pour rechercher une transaction et voir son historique ;
• un export compatible avec votre outil comptable ;
• une procédure claire pour les remboursements et les litiges.

Tester avant d'ouvrir les vannes

Utilisez systématiquement l'environnement de test du prestataire, puis réalisez de vrais paiements de faible montant en production avant l'ouverture au public. Testez en particulier les cas d'échec : solde insuffisant, refus de l'utilisateur, délai expiré, notification reçue deux fois, serveur indisponible au moment de la notification.

Check-list technique

• Clés d'API stockées uniquement côté serveur.
• Notifications vérifiées (signature et/ou interrogation de l'API).
• Traitement idempotent des confirmations.
• Statuts intermédiaires modélisés et tâche de vérification des transactions en attente.
• Journal des transactions et export pour le rapprochement.
• Parcours utilisateur testé sur des cas de réussite et d'échec.
• Intégration du prestataire isolée pour pouvoir en changer.

Conclusion

Intégrer le mobile money dans une application est tout à fait accessible, à condition de traiter le paiement comme un processus asynchrone, de sécuriser la chaîne côté serveur et de soigner les cas d'échec. Ce sont ces détails qui font la différence entre une application qui encaisse de manière fiable et une application qui génère des réclamations.

Vous avez un projet de plateforme, de boutique ou d'application qui doit encaisser des paiements ? L'équipe KODEX CracLabs peut vous aider à choisir l'architecture adaptée et à la mettre en œuvre. Contactez-nous.