Encaisser en Afrique sans exclure la moitié de ses clients
MTN MoMo, Orange Money, Wave, Airtel, M-Pesa d'un côté ; Visa et Mastercard de l'autre. Ce qu'on apprend en branchant un tunnel de paiement pour un marché où la carte bancaire est minoritaire.
La carte bancaire n'est pas le moyen de paiement par défaut
C'est l'hypothèse implicite de la plupart des intégrations de paiement : on branche un prestataire européen ou américain, on affiche Visa et Mastercard, et on considère le sujet réglé. Dès qu'une partie de votre audience est au Cameroun, au Sénégal ou en Côte d'Ivoire, ça revient à construire un tunnel de paiement que ces acheteurs-là ne peuvent pas terminer.
Le paiement passe par le mobile. Ce n'est pas un détail d'implémentation à traiter en fin de projet : c'est une décision produit qui conditionne le taux de conversion de tout ce qu'il y a en amont.
Deux agrégateurs plutôt qu'un
Sur un projet récent, le public était francophone au sens large : l'Europe, l'Afrique de l'Ouest et centrale, l'Amérique du Nord. Ces publics ne paient pas de la même manière et un prestataire unique en aurait forcément exclu une partie. La solution a été d'assembler deux briques complémentaires : un agrégateur spécialisé Mobile Money multi-pays d'un côté, un prestataire orienté carte bancaire internationale de l'autre.
Le marché offre plusieurs options pour chaque brique. Côté Mobile Money, des solutions comme PawaPay, Flutterwave ou CinetPay couvrent les opérateurs de plusieurs pays africains ; côté carte internationale, des prestataires comme Dodo Payments, Stripe ou Lemon Squeezy gèrent en plus la partie fiscale et les devises. Le bon assemblage dépend de votre géographie, pas d'une recommandation universelle.
Sur la Résidence Kesla, le public est local : NotchPay suffisait, avec une couverture des opérateurs camerounais. Le choix de l'agrégateur se fait sur la géographie réelle des acheteurs, pas sur la notoriété du prestataire.
Le statut de paiement est une fonctionnalité, pas un log
C'est la principale différence avec un paiement par carte. Une transaction Mobile Money peut rester en attente, expirer sans notification, ou échouer côté opérateur sans que votre application en soit informée proprement. Si votre back-office ne montre pas ces statuts, c'est le client qui vous les apprendra, par téléphone, et mécontent.
Sur Kesla, le tableau de bord des paiements avec leurs statuts fait partie du produit, au même titre que la réservation elle-même. C'est ce qui permet au propriétaire de savoir, sans moi, si un séjour est réellement payé.
Un paiement mobile qui échoue ne prévient pas toujours. Si votre back-office ne montre pas les statuts, c'est le client qui vous les apprendra.
Tester le tunnel avant d'y mettre de l'argent
J'ai validé les réponses des API avec Postman et cURL avant même de les intégrer, puis couvert le parcours d'achat de bout en bout avec Cypress. Sur un tunnel de paiement, la couverture de tests n'est pas une question de rigueur : une transaction perdue, c'est un client perdu, et la confiance ne revient pas.
Le détail qui coûte une demi-journée : les logos
Afficher les moyens de paiement acceptés n'est pas cosmétique. C'est ce qui dit à l'acheteur, avant qu'il ne saisisse quoi que ce soit, qu'il pourra payer avec ce qu'il a. Il me fallait donc les logos de MTN MoMo, Orange Money, Wave, Airtel, M-Pesa, Visa, Mastercard, Google Pay, Klarna.
Trouver des logos en bonne qualité et libres d'utilisation est plus compliqué qu'il n'y paraît, et les bibliothèques classiques ignorent complètement l'univers du Mobile Money. J'ai fini par utiliser logos.lndev.me, construit par Leonel Ngoya : 15 000 logos SVG, recherche instantanée, export direct dans le framework de votre choix, et surtout les opérateurs africains présents. Quelques minutes au lieu d'une demi-journée.
Une bibliothèque de logos construite par un développeur camerounais et utilisée par des développeurs du monde entier : c'est aussi une réponse à la question de savoir si l'écosystème africain produit des outils, ou seulement des utilisateurs.