FedaPay ou CinetPay : quel agrégateur choisir au Bénin

FedaPay ou CinetPay ? La question arrive toujours au même moment, et le scénario qui l’amène se répète chez presque tous les commerçants qui vendent en ligne au Bénin. Le site est prêt, le catalogue est chargé, il reste « juste à brancher le Mobile Money ». Deux semaines plus tard, les paiements passent. Mais la caissière tient un cahier parallèle, parce que trois commandes sur cent apparaissent payées côté client et impayées côté site, et personne ne sait laquelle des deux versions est la bonne.

Encaisser par Mobile Money n’est pas un problème de bouton, c’est un problème de comptabilité distribuée. Votre serveur, l’agrégateur et l’opérateur télécom détiennent chacun une version de la même transaction, et ces trois versions ne se synchronisent pas d’elles-mêmes. Cet article compare ce que couvrent réellement FedaPay, CinetPay, MTN MoMo et Moov Money, explique comment se forment les commissions et les délais de reversement, puis détaille les pannes qui reviennent systématiquement en production. Les grilles tarifaires évoluent et se négocient : les ordres de grandeur donnés ici sont des repères de discussion, pas des tarifs officiels.

Quatre besoins derrière « accepter le Mobile Money »

Avant de comparer les prestataires, il faut savoir ce que vous achetez. Quatre besoins distincts se cachent derrière « accepter le Mobile Money », et ils ne s’ouvrent pas au même moment ni aux mêmes conditions.

La collecte : encaisser un client depuis son portefeuille MTN MoMo ou Moov Money. C’est le seul besoin couvert par la plupart des intégrations rapides.
Le reversement (payout) : envoyer de l’argent depuis votre compte marchand vers des portefeuilles — commissions de vendeurs, remboursements, paiement de chauffeurs ou de livreurs.
Le remboursement : annuler tout ou partie d’un encaissement. Rarement automatisé, souvent manuel depuis le tableau de bord du prestataire.
La réconciliation : rapprocher chaque jour ce que dit votre base de données et ce que dit le prestataire. C’est le chantier que tout le monde reporte, et celui dont l’absence coûte le plus cher.

Une marketplace ou une plateforme de transport a besoin des quatre. Une boutique en ligne classique a besoin des deux premiers. Posez la question avant de signer : « le payout est-il ouvert sur mon compte, sous quelles conditions et avec quel plafond ? » La réponse n’est pas systématiquement oui, et elle dépend souvent de votre historique de volume.

Agrégateur ou connexion directe à l’opérateur

Un agrégateur (FedaPay, CinetPay) vous donne une seule API, un seul contrat et un seul tableau de bord pour plusieurs portefeuilles et les cartes bancaires. Il absorbe les particularités de chaque opérateur et vous facture une commission un peu plus élevée pour ce service. C’est le bon choix dans la très grande majorité des cas, en particulier si votre équipe technique compte moins de trois personnes.

Une connexion directe à l’opérateur (l’API MTN MoMo, ou une convention avec Moov) supprime un intermédiaire et peut améliorer la commission au volume. En contrepartie, vous signez un contrat par opérateur, vous gérez deux intégrations différentes, deux formats de rapport et deux interlocuteurs support. Le calcul devient intéressant à partir d’un volume mensuel important et régulier, jamais au démarrage.

Acteur	Type	Couverture typique	À privilégier quand
FedaPay	Agrégateur béninois	MTN MoMo Bénin, Moov Money Bénin, cartes bancaires, ouverture à d’autres pays UEMOA	Vous vendez d’abord au Bénin et voulez un interlocuteur joignable localement
CinetPay	Agrégateur régional	Large éventail de portefeuilles UEMOA et au-delà, cartes, page de paiement hébergée	Vous encaissez dans plusieurs pays avec une seule intégration
MTN MoMo API	Opérateur	Collection, Disbursement, Remittance — uniquement le réseau MTN	Volume élevé sur MTN, besoin de payout de masse, équipe technique disponible
Moov Money	Opérateur	Portefeuille Moov, accès API par convention commerciale	Clientèle majoritairement Moov, ou en complément d’un agrégateur

FedaPay ou CinetPay : ce qui les sépare vraiment

Sur le papier, les deux agrégateurs font la même chose. En pratique, le choix se joue sur trois détails : la proximité du support, la couverture au-delà du Bénin, et ce qui est réellement activé sur votre compte. Les deux opérateurs, eux, se traitent soit en direct, soit à travers l’agrégateur que vous aurez retenu.

FedaPay propose un environnement de test complet et des bibliothèques dans les langages courants, ce qui raccourcit sérieusement la première intégration. L’avantage réel n’est pas technique : c’est de pouvoir appeler quelqu’un à Cotonou quand une transaction reste bloquée un vendredi soir.

CinetPay a du sens dès que vous encaissez hors du Bénin. Une seule page de paiement couvre plusieurs portefeuilles nationaux, ce qui évite de multiplier les contrats. Vérifiez pays par pays quels moyens sont réellement activés sur votre compte : la liste commerciale et la liste effective ne coïncident pas toujours.

L’API MTN MoMo expose un environnement de bac à sable public, mais le passage en production suppose un accord avec l’entité MTN du pays. Bonne nouvelle pour les développeurs : l’API impose un identifiant de référence unique par requête, ce qui vous force à faire de l’idempotence dès le premier jour.

Moov Money documente moins publiquement son API. Dans la pratique, beaucoup d’entreprises y accèdent via un agrégateur plutôt qu’en direct, sauf projet à fort volume justifiant la négociation d’une convention.

Comment se forment réellement les commissions

La commission n’est jamais un chiffre unique. Elle se décompose en quatre lignes qu’il faut faire écrire noir sur blanc dans le contrat.

Commission de collecte : un pourcentage du montant encaissé, différent selon l’instrument. L’ordre de grandeur observé sur le marché ouest-africain se situe entre 1,5 % et 3,5 % sur portefeuille mobile, un peu plus sur carte bancaire, souvent avec un frais fixe additionnel. Estimation à confirmer auprès de chaque prestataire.
Frais de reversement : facturés à l’envoi vers un portefeuille, en montant fixe ou en pourcentage. C’est la ligne oubliée des marketplaces qui reversent des centaines de petites sommes.
Frais de virement bancaire : quand vous rapatriez votre solde marchand vers votre compte en banque.
Frais fixes : ouverture de compte, abonnement mensuel, accès à certaines fonctions. Souvent nuls chez les agrégateurs, à vérifier quand même.

Faites l’arithmétique avant de choisir, pas après. Sur un panier moyen de 5 000 FCFA à 2 % de commission, vous laissez 100 FCFA par transaction. À 2 000 transactions par mois, cela représente 200 000 FCFA mensuels, soit 2 400 000 FCFA par an. Un demi-point de commission négocié vaut alors 600 000 FCFA par an — largement de quoi justifier une discussion sérieuse au moment où votre volume devient prévisible.

Reste la question politique : qui paie ? Répercuter les frais au client est courant, mais cela augmente le taux d’abandon au moment du paiement. Les absorber protège la conversion mais mange la marge. Tranchez explicitement, affichez-le clairement sur la page de paiement, et ne changez pas d’avis tous les mois.

Délais de reversement : un sujet de trésorerie avant d’être un sujet technique

L’argent encaissé n’arrive pas immédiatement sur votre compte bancaire. Selon le prestataire et le type de compte, le délai constaté va généralement de J+1 à J+7 ouvrés, avec une pratique fréquente autour de J+2 ou J+3. Ce décalage est structurant si vous devez payer des fournisseurs à réception.

Quatre questions à poser, dont les réponses doivent figurer par écrit :

Quelle est l’heure limite quotidienne au-delà de laquelle une transaction bascule sur le jour suivant ?
Les délais sont-ils comptés en jours ouvrés ou calendaires, et que se passe-t-il autour des jours fériés ?
Existe-t-il un seuil minimum de solde en dessous duquel aucun reversement n’est déclenché ?
Le reversement peut-il être automatique et programmé, ou faut-il le demander manuellement ?

Ce qui casse en production

Le webhook qui n’arrive pas

Le prestataire notifie votre serveur quand une transaction change d’état. Sauf que votre serveur était en cours de redémarrage, que la coupure de courant a duré plus longtemps que l’onduleur, ou que le certificat HTTPS a expiré la nuit. La notification est perdue, et la commande reste « en attente » pour l’éternité.

La règle est simple : ne jamais dépendre uniquement du webhook. Répondez en HTTP 200 immédiatement, traitez le contenu de manière asynchrone, et ajoutez une tâche périodique qui interroge l’API sur toutes les transactions non finalisées depuis plus de quelques minutes. Vérifiez systématiquement la signature de la notification et enregistrez la charge utile brute avant de la traiter : le jour du litige, ce journal est votre seule preuve.

L’absence d’idempotence

Un webhook peut être envoyé deux fois. Un client impatient peut cliquer trois fois. Un mécanisme de reprise peut rejouer une requête. Sans protection, le même paiement crédite le compte trois fois, ou déclenche trois livraisons.

La parade tient en quelques lignes : générez vous-même une référence unique par tentative de paiement, stockez l’identifiant de transaction du prestataire avec une contrainte d’unicité en base de données, et traitez le passage d’un état à l’autre comme une machine à états — une transaction déjà marquée « payée » ignore silencieusement toute notification ultérieure. La contrainte d’unicité en base est la protection la plus fiable, parce qu’elle tient même quand deux processus s’exécutent en parallèle.

Le statut « en attente » éternel

L’utilisateur a lancé le paiement mais n’a jamais saisi son code sur le message USSD. Sur le réseau, l’écran s’est fermé. Côté opérateur, la transaction expire au bout d’un certain temps ; côté vous, elle reste ouverte si personne ne l’a prévu. Définissez une durée de vie explicite, interrogez l’API une dernière fois avant d’expirer une transaction, et n’annulez jamais une commande sans cette dernière vérification.

La réconciliation absente

C’est le point qui distingue une intégration amateur d’une intégration exploitable. Chaque nuit, comparez la liste de vos transactions du jour avec le rapport du prestataire, ligne à ligne, sur trois champs : référence, montant, statut. Toute divergence déclenche une alerte lisible par un humain, pas une ligne perdue dans un fichier de journalisation. Sur les intégrations que nous avons mises en production chez IK’ART, ce rapprochement quotidien est ce qui a le plus réduit les litiges, davantage que n’importe quelle optimisation de l’appel API.

Check-list avant la mise en ligne

Les clés de production sont hors du code source et hors de tout dépôt de code.
La signature des notifications est vérifiée, et une notification non signée est rejetée.
Une contrainte d’unicité en base empêche le double crédit.
Une tâche périodique réconcilie les transactions non finalisées.
Un rapprochement quotidien compare votre journal et celui du prestataire.
Les montants sont stockés en entiers (en francs CFA), jamais en nombres à virgule flottante.
Un test a été réalisé avec un vrai portefeuille MTN et un vrai portefeuille Moov, sur un petit montant.
Le comportement en cas d’échec est écrit et testé : que voit le client, que voit la caisse, qui est alerté.

Comptez, en ordre de grandeur, cinq à dix jours-homme pour une première intégration propre chez un agrégateur sur un site existant, réconciliation comprise. Une connexion directe à un opérateur demande davantage, et le délai réel dépend surtout de la vitesse de signature du contrat, pas du code.

Ce qu’il faut faire cette semaine

Si vous démarrez, commencez par un agrégateur et un seul, en mode test, avec un montant réel de 100 FCFA le jour du passage en production. Écrivez d’abord la table qui stocke vos transactions et sa contrainte d’unicité, avant d’écrire le premier appel API : c’est l’inverse de l’ordre naturel, et c’est ce qui vous évitera de reconstruire l’intégration six mois plus tard.

Si vous avez déjà une intégration en ligne, faites un seul exercice : exportez le rapport du prestataire pour le mois dernier, exportez vos propres transactions, et comparez-les. Le nombre de lignes qui ne correspondent pas vous dira exactement combien de travail il reste — et si ce nombre est zéro, votre intégration est en meilleur état que la moyenne.

Si vous préférez déléguer le chantier, notre prestation d’intégration Mobile Money démarre à 750 000 FCFA hors taxes sur un projet existant, pour un délai de deux à quatre semaines ; l’ajout d’un opérateur de paiement sur une intégration déjà en place est facturé 350 000 FCFA hors taxes, pour environ une semaine de travail. Dans les deux cas, le devis chiffré en FCFA part sous 48 heures après le cadrage, et la réconciliation quotidienne fait partie de la livraison, pas des options. Nous intervenons quel que soit l’environnement technique de votre site existant : l’intégration se greffe sur ce que vous avez déjà, sans migration imposée.