Pourquoi les agrégateurs de paiement africains négligent-ils les développeurs ?

Pour encaisser un paiement en ligne en Afrique, on passe presque toujours par un agrégateur de paiement (un PSP, prestataire de services de paiement), un intermédiaire qui relie le site du marchand aux opérateurs mobile money et aux cartes bancaires. Se brancher directement sur l’API mobile money d’un opérateur reste possible, mais c’est presque hors de portée d’un marchand ordinaire : très peu de documentation publique, rarement de sandbox. 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. Je compare ici ce que chacun fournit à celui qui l’intègre. Et je n’arrive pas à comprendre pourquoi des acteurs qui ont des équipes techniques, et qui sont installés depuis des années, livrent une expérience développeur (la DX) aussi inégale.

Ce qu’un bon agrégateur livre#

Pour moi, un agrégateur sérieux fournit cinq choses à celui qui l’intègre :

• une documentation publique, lisible avant même d’ouvrir un compte ;
• une sandbox, pour tester sans argent réel ;
• des webhooks signés (les notifications de paiement envoyées à notre serveur), accompagnés d’une signature qui prouve que la confirmation vient bien du fournisseur ;
• des SDK officiels (bibliothèques de code), pour brancher son application sans tout réécrire ;
• des tarifs publics, et si possible quelques indicateurs comme le taux de succès ou l’uptime (la disponibilité).

Stripe a posé ce standard il y a plus de dix ans. Il est documenté, et des acteurs africains le tiennent déjà, comme Paystack, Flutterwave et plusieurs agrégateurs régionaux. On peut donc l’attendre ici aussi. Voici l’écart à ce niveau, acteur par acteur.

Acteur par acteur#

PayGate#

Chez PayGate, je n’ai pu lire la documentation qu’une fois le compte marchand activé, après l’envoi des papiers de l’entreprise et l’attente de la validation. Avant ça, il n’y a rien à consulter, donc rien à comparer. Une fois dedans, le dashboard (tableau de bord) tient en cinq écrans, la clé d’API s’affiche en clair à chaque connexion, et le webhook de confirmation arrive sans signature. Les cartes bancaires sont annoncées « sous peu » sur la page d’accueil depuis 2016 et ne sont toujours pas disponibles. Les logos d’opérateurs du site portent encore des marques qui n’existent plus.

Pour l’intégrateur, ça veut dire tester en production, faute de sandbox, et coder soi-même la vérification que chaque confirmation vient bien de PayGate. En dix ans, le produit n’a pas bougé, et pendant ce temps la référence a monté.

Qosic#

Chez Qosic, la documentation est publique, les codes de statut sont clairs et les tarifs sont affichés, donc la prise en main se passe bien. Ça se complique après. Le webhook de confirmation n’est pas signé et annonce un montant auquel il ne faut pas se fier, alors que la confirmation de référence ne renvoie pas de montant du tout. Et tant que la transaction n’est pas tranchée, il faut faire du polling (interroger leur API en boucle) pour connaître son issue.

J’ai donc dû stocker le montant de la commande de mon côté, réconcilier chaque paiement à la main et maintenir un polling dont d’autres fournisseurs se passent.

CashPay (Semoa)#

Sur le papier, l’offre de CashPay est large : cartes bancaires, mobile money, portefeuilles, plusieurs pays. Côté intégration, c’est beaucoup plus flou. La documentation se résume à une collection Postman, sans guide qui explique le parcours de bout en bout. On ne peut rien faire seul en ligne : il faut prendre contact avec leur équipe, et l’essentiel se débloque après la signature d’un contrat. La sandbox et le dashboard existent, mais on n’y accède qu’une fois le compte créé. Je n’ai pas trouvé non plus de grille tarifaire claire.

En pratique, on évalue sur des exemples de requêtes, et on ne connaît le vrai coût qu’après la discussion commerciale.

FedaPay#

FedaPay est celui qui s’approche le plus de cette référence : documentation publique, sandbox en libre-service, SDK officiels, cartes gérées. J’y ai migré un projet en 2021, quand PayGate ne suffisait plus, et j’ai vu la différence dès la première heure. Le fournisseur faisait sa part, je n’avais pas à écrire de rustines pour combler ses manques. Le coût d’intégration est faible, et c’est à lui que je compare les autres.

Kkiapay#

J’ai branché Kkiapay récemment pour un test. La sandbox marche sans configuration, les numéros de test sont publics, et il y a des SDK pour la plupart des langages ainsi que des plugins e-commerce. J’étais opérationnel en une après-midi, sans parler à un commercial. Le standard dont je parlais plus haut, un acteur béninois le tient.

Wave#

Wave n’est pas un agrégateur mais un portefeuille mobile, et techniquement c’est le plus solide que j’aie vu. Sa documentation est publique, on peut tout lire avant d’ouvrir un compte, et elle tient un changelog daté depuis le lancement de l’API en 2022.

On sent une équipe qui a pensé à celui qui intègre. Les webhooks sont signés en HMAC-SHA256, avec un horodatage qui protège contre le rejeu (replay). Chaque clé d’API peut être limitée à certaines API et à certaines adresses IP, et on peut exiger que nos propres appels à Wave soient signés eux aussi. Les erreurs arrivent en JSON avec un code et un message lisibles. La documentation dit aussi franchement ce qui peut mal se passer : un webhook peut arriver deux fois, en retard ou dans le désordre, et Wave réessaie pendant trois jours si notre serveur ne répond pas. D’habitude, ce genre de détail se découvre en production.

Deux manques quand même. Aucune sandbox n’est documentée : les exemples utilisent des clés de production, et il faut un compte Wave Business validé avant le premier appel. Il n’y a pas non plus de SDK officiel, seulement des exemples en cURL, PHP, JavaScript et Java.

Sur la signature des webhooks, un acteur d’une autre catégorie fait donc mieux que des agrégateurs dont c’est le métier, ce qui rend difficile d’expliquer leurs manques par un manque de moyens.

Le comparatif#

Je ne donne pas de note globale, parce que le poids de chaque critère serait arbitraire. Le tableau dit seulement si chaque élément est présent, partiel ou absent, ce qu’un développeur peut vérifier lui-même.

Tableau établi à partir de mes intégrations et de la documentation publique de chaque acteur. Le détail critère par critère, avec les sources, est dans le registre ouvert Afrotools. Si une case est fausse, dites-le-moi.

Ce que coûte l’absence de ces briques#

Aucune de ces briques n’est lourde à fournir. Une documentation publique tient sur une page web, une sandbox demande un jeu de fausses données, et les bibliothèques standard savent signer un webhook en quelques lignes. Pour une entreprise qui emploie déjà des développeurs, ça se compte en jours de travail.

Quand elles manquent, c’est quelqu’un d’autre qui paie. L’intégrateur écrit des rustines défensives, ou conseille un autre fournisseur à son client suivant. L’entreprise cliente paie parfois plus cher un service qui lui demande plus de travail. Quant à l’acteur installé, sa notoriété, la redirection des opérateurs et ses années de relation le protègent tant qu’aucun concurrent n’arrive avec une meilleure intégration. Le jour où ça arrive, cet avantage peut fondre vite.

Pourquoi ils ne le font pas : trois hypothèses#

Je n’ai pas la réponse, seulement trois hypothèses, de la plus probable à la moins probable.

La première, c’est l’absence de pression. Quand les opérateurs envoient d’office les clients vers un agrégateur, séduire les développeurs ne rapporte rien de visible. C’est l’explication la plus simple, et sans doute la principale.

La deuxième, c’est une culture d’exploitation plus que de produit. Tant que l’argent rentre et que ça tourne, on ne touche à rien, et le développeur qui intègre est vu comme un détail de mise en œuvre plutôt que comme un utilisateur.

La troisième tient au mode de vente. 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 technique, ce sont des choix de priorité. C’est la question que je pose aux acteurs cités, sans leur faire de procès : qu’est-ce qui rend ces briques moins prioritaires que le reste ?

Pourquoi j’écris ça#

Je ne suis ni client final ni concurrent de ces acteurs. Je suis un développeur africain qui les a intégrés, et je préférerais les voir garder ce marché plutôt que le perdre parce que l’ingénierie a été négligée. Le marché s’ouvre, et l’avance historique ne suffira pas.

Tout ce qui est écrit ici vient de mes intégrations et de documentations publiques. C’est un retour d’expérience de développeur, que n’importe quel intégrateur peut refaire de son côté : je n’ai mené aucun test de sécurité. Quand j’écris « webhook non signé », je décris ce que j’ai reçu en intégrant, pas une faille que j’aurais cherchée. Et si un point factuel est faux, je le corrige dans l’article, de façon visible.

Et vous, qu’avez-vous intégré ?#

Je n’ai intégré qu’une petite partie des moyens de paiement du continent. Il en existe des dizaines d’autres, d’un pays à l’autre, et beaucoup d’entre vous en ont sûrement une expérience que je n’ai pas.

Alors racontez-moi. Quel PSP ou quel moyen de paiement avez-vous intégré, et comment ça s’est passé ? Côté produit : l’ouverture du compte, les tarifs, le support, les délais de reversement. Côté technique : la doc, la sandbox, les webhooks, les SDK, ce qui vous a fait perdre du temps. Une bonne surprise m’intéresse autant qu’une galère. Et si j’ai raté une fonctionnalité récente chez un acteur cité, ou si vous avez réussi une intégration là où je décris l’inverse, dites-le aussi : je corrige.

Répondez en commentaire sous le post qui partage cet article, ou écrivez-moi directement.

Si vous intégrez des API africaines, jetez aussi un œil à Afrotools, un registre open source de spécifications d’API africaines, vérifiées sur les vraies API, que chacun peut enrichir.