Encaisser un paiement en ligne en Afrique passe presque toujours par un agrégateur : un intermédiaire qui relie une boutique aux opérateurs mobile money et aux cartes bancaires. Le choix de cet intermédiaire retombe sur le développeur ou l’agence qui va l’intégrer, le maintenir, et vivre avec ses défauts pendant des années.
J’en ai intégré plusieurs, sur des projets clients et sur mes propres produits. Ce texte compare ce que chacun fournit à celui qui l’intègre, et pose une question : pourquoi des acteurs équipés d’équipes techniques et installés depuis des années livrent-ils une expérience développeur aussi inégale ?
Ce qu’un bon agrégateur livre
Avant de comparer, fixons la référence. Un agrégateur sérieux fournit cinq choses à celui qui l’intègre :
- une documentation publique, lisible avant même d’ouvrir un compte ;
- un mode test, pour essayer sans argent réel ;
- des notifications de paiement signées, c’est-à-dire accompagnées d’un code qui prouve que la confirmation vient bien du fournisseur ;
- des bibliothèques officielles, pour brancher son code sans le réécrire ;
- des tarifs publics, et si possible quelques indicateurs : taux de réussite, disponibilité.
Rien d’exotique là-dedans. Stripe a posé ce standard il y a plus de dix ans, et des acteurs africains le tiennent déjà : Paystack, Flutterwave, plusieurs agrégateurs régionaux. Le niveau attendu n’est ni théorique ni réservé à l’Occident : il est documenté, atteint, reproductible. Ce qui suit mesure l’écart à ce niveau, acteur par acteur.
Acteur par acteur
PayGate
Pour lire la documentation, il faut déjà un compte marchand activé : papiers d’entreprise, validation, attente. Avant cette étape, rien n’est consultable, donc rien n’est comparable. Une fois à l’intérieur, le tableau de bord tient en cinq écrans, la clé d’accès s’affiche en clair à chaque connexion, et la confirmation de paiement arrive sans signature. Les cartes bancaires, annoncées « sous peu » sur la page d’accueil depuis 2016, ne sont toujours pas disponibles ; les logos d’opérateurs affichés sur le site portent encore des marques qui n’existent plus.
Côté intégrateur, le coût est concret : tester en production faute de mode test, et coder soi-même la vérification que chaque confirmation provient réellement de PayGate. Le produit n’a pas régressé en dix ans ; il n’a pas bougé, pendant que la référence, elle, montait.
Qosic
La documentation est publique, les codes de statut sont clairs, les tarifs affichés : la prise en main est correcte. Le problème est plus loin. La confirmation de paiement n’est pas signée, et elle annonce un montant auquel il ne faut pas se fier, tandis que la confirmation de référence, elle, ne renvoie pas le montant du tout. Tant que la transaction n’est pas tranchée, il faut interroger le serveur en boucle pour connaître son issue.
Côté intégrateur : stocker le montant de la commande de son côté, réconcilier chaque paiement à la main, et maintenir une boucle de vérification que d’autres fournisseurs rendent inutile.
CashPay (Semoa)
Sur le périmètre fonctionnel, c’est le plus complet du lot : cartes bancaires opérationnelles via la passerelle d’Orabank, extensions WooCommerce et PrestaShop, liens de paiement, QR codes, présence dans plusieurs pays. C’est, sur le papier, ce que PayGate promet sans le livrer.
(Mon retour d’intégration — documentation, mode test, comportement réel des cartes, support — s’insère ici. Section à compléter.)
FedaPay
C’est la référence atteinte de près : documentation publique, mode test en libre-service, bibliothèques officielles, cartes gérées. J’y ai migré un projet en 2021, quand PayGate ne suffisait plus, et l’écart se mesure dès la première heure d’intégration : le fournisseur fait sa part, l’intégrateur n’écrit pas de rustines pour combler des manques.
Côté intégrateur, le coût est faible. C’est le repère par rapport auquel les autres se situent.
Les contre-exemples
Kkiapay, branché récemment pour un test, va dans le même sens : un mode test qui fonctionne sans configuration, des numéros de test publics, des bibliothèques pour la plupart des langages, des extensions e-commerce. Opérationnel en une après-midi, sans passer par un commercial. C’est le standard décrit plus haut, tenu par un acteur béninois.
Wave, qui n’est pas un agrégateur mais un portefeuille, signe correctement ses notifications. Quand un acteur d’une autre catégorie tient le standard mieux que des agrégateurs sur leur propre métier, l’argument du manque de moyens perd l’essentiel de sa force.
Le comparatif
Pas de note globale : son poids serait arbitraire. Seulement ce qu’un développeur peut vérifier — présent, partiel ou absent — chez chacun.
| Doc publique | Bac à sable | Notif scellée | SDK officiels | Cartes bancaires | Multi-pays | |
|---|---|---|---|---|---|---|
| Kkiapay | ✓ | ✓ | ◐ | ✓ | ✓ | ✓ |
| FedaPay | ✓ | ✓ | ◐ | ✓ | ✓ | ✓ |
| CashPay (Semoa) | ◐ | ◐ | ◐ | ◐ | ✓ | ✓ |
| Qosic | ✓ | ◐ | ✗ | ◐ | ◐ | ◐ |
| PayGate | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
✓ disponible · ◐ partiel ou à confirmer · ✗ absent. Tableau établi à partir de mes intégrations et de la documentation publique de chaque acteur ; la ligne CashPay sera figée une fois mon retour terminé. Le détail critère par critère, avec sources, vit dans le registre ouvert Afrotools. Corrections bienvenues.
Le coût de ne pas le faire
Aucune de ces briques n’est lourde. Une documentation publique, c’est une page web. Un mode test, c’est un jeu de fausses données. Une signature sur les notifications, c’est une fonction que les bibliothèques standard posent en quelques lignes. Pour une organisation qui emploie déjà des développeurs, l’unité de mesure est le jour, pas le trimestre.
L’absence, elle, a un coût qui retombe ailleurs. L’intégrateur écrit des rustines défensives, ou recommande un autre fournisseur au client suivant. L’entreprise paie parfois plus cher un service qui lui demande plus de travail. Et l’avantage de l’acteur installé — notoriété, redirection des opérateurs, années de relation — tient tant qu’aucun concurrent ne se présente avec une meilleure expérience d’intégration. Quand l’un d’eux le fait, l’avantage fond vite.
La vraie question : qu’est-ce qui les empêche ?
Reste le fond : pourquoi des acteurs équipés ne livrent-ils pas ces briques ? Trois hypothèses, par ordre de vraisemblance.
L’absence de pression, d’abord. Quand les opérateurs redirigent les clients d’office, séduire un développeur n’a pas de retour sur investissement visible. C’est l’explication la plus simple, et probablement la principale.
Une culture d’exploitation plutôt que de produit, ensuite : on encaisse, ça fonctionne, on n’y touche pas. Le développeur qui intègre n’est pas traité comme un utilisateur à servir, mais comme un détail de mise en œuvre.
Un modèle de vente en relationnel plutôt qu’en libre-service, enfin. Un fournisseur qui signe ses clients en réunion n’a pas besoin qu’un inconnu réussisse seul son intégration, à partir d’une documentation publique.
Aucune de ces raisons n’est une contrainte technique. Ce sont des arbitrages : de temps, d’attention, de priorité. C’est sur cet arbitrage que porte la question, posée aux acteurs cités sans procès — qu’est-ce qui rend ces briques moins prioritaires que le reste ?
Pourquoi ce post
Je ne suis ni client final ni concurrent de ces acteurs : un développeur africain qui les a intégrés de l’intérieur, et qui préférerait les voir tenir ce marché plutôt que le céder par négligence d’ingénierie. Le marché s’ouvre ; l’avantage historique ne se reconduit pas seul.
J’ai partagé ce texte avec les acteurs cités avant publication : tout point factuel erroné sera corrigé, visiblement, dans le corps de l’article. Je ne décris aucune méthode d’attaque — « notification non signée » désigne un défaut de robustesse, pas un mode d’emploi.
Le détail des critères, les sources et le comparatif complet vivent dans un registre ouvert, Afrotools, reproductible et ouvert à contribution. Un contre-exemple — une fonctionnalité récente que j’aurais manquée, un cas où les cartes fonctionnent vraiment, une intégration réussie là où je décris l’inverse — et je l’intègre.