Il existe deux façons d'encaisser du Mobile Money au Cameroun, et elles ne se valent pas. La première est disponible tout de suite. La seconde demande un contrat avec l'opérateur. Beaucoup de commerçants perdent des semaines à attendre la seconde alors qu'ils pouvaient déjà vendre avec la première — et beaucoup d'autres restent bloqués sur la première sans mesurer ce qu'elle leur coûte en travail manuel.
Le code marchand, concrètement
MTN et Orange délivrent un code marchand bien avant d'ouvrir l'accès à leur API. Le client compose un code USSD sur son téléphone — *126# chez MTN, #150# chez Orange —, choisit le paiement marchand, saisit votre code, le montant, puis son code secret. Il reçoit un SMS de confirmation contenant un identifiant de transaction.
C'est simple, ça marche partout, et ça ne demande aucune intégration technique. Un commerçant qui a son code peut encaisser le jour même.
Sa limite, et elle est structurelle
L'opérateur ne vous notifie de rien. Aucun appel entrant sur votre serveur, aucun statut à interroger, aucun moyen automatique de savoir qu'un paiement vient d'arriver. Le code marchand est un tuyau à sens unique : l'argent passe, l'information non.
Ce n'est pas un défaut d'intégration qu'on pourrait contourner avec un peu de code. C'est la nature même du produit. Chez WalleoPay, le pilote de paiement par code marchand assume cette limite au lieu de la masquer : il place le paiement en attente de confirmation, affiche au client les instructions USSD, et s'arrête là. Interrogé sur le statut, il répond invariablement « toujours en attente », parce qu'il n'a aucune source de vérité à consulter.
Trois conséquences pratiques :
- Aucune confirmation automatique. Le client saisit lui-même l'identifiant reçu par SMS, et quelqu'un doit valider en rapprochant avec le relevé Mobile Money du compte marchand.
- Un rapprochement manuel, chaque jour. Plus vous vendez, plus cette tâche grossit. À quelques transactions par jour c'est anecdotique ; à plusieurs dizaines, c'est un poste de travail.
- Pas de reversement automatisé. Sortir l'argent se fait depuis l'application MoMo, à la main.
Il faut ajouter une quatrième conséquence, moins visible : la fraude à la capture d'écran. Quand la preuve de paiement est un SMS ou une capture, elle se fabrique. Un identifiant de transaction ne vaut que confronté au relevé réel.
Ce que l'API change
Avec un contrat opérateur, le mécanisme s'inverse. Votre serveur demande le paiement, l'opérateur pousse une notification sur le téléphone du client, celui-ci saisit son code secret, et le résultat vous revient.
Chez MTN, la séquence est claire : la demande d'encaissement renvoie un statut 202 sans corps, accompagnée d'une référence que vous avez vous-même générée et transmise dans l'en-tête X-Reference-Id. C'est cette référence qui permet ensuite d'interroger le statut de l'opération, autant de fois que nécessaire, jusqu'à ce qu'elle soit réussie ou échouée. En parallèle, l'opérateur rappelle l'adresse de callback fournie à la demande.
Ce que vous gagnez :
- Une source de vérité interrogeable. Vous pouvez toujours redemander « où en est ce paiement ? » et obtenir une réponse qui engage l'opérateur.
- Une confirmation en quelques secondes. Votre site peut livrer tout seul, sans intervention humaine.
- Un motif d'échec exploitable. Solde insuffisant, plafond dépassé, code non saisi à temps : vous savez quoi dire au client au lieu d'un « ça n'a pas marché » générique.
- Des reversements programmables. Le produit de décaissement permet d'envoyer de l'argent vers un numéro sans passer par l'application.
Deux pièges méritent d'être connus avant de signer. Le bac à sable de MTN n'accepte que l'euro comme devise, quelle que soit la devise réelle de la transaction — la production, elle, travaille en francs CFA. Et l'adresse de production est propre à chaque compte, attribuée au moment de la mise en service : ce n'est pas l'hôte du bac à sable avec un mot changé.
Comment arbitrer
Prenez le code marchand si vous vendez en discutant avec vos clients — messagerie, téléphone, comptoir —, si vos volumes tiennent dans un rapprochement quotidien de quelques minutes, ou si vous voulez simplement commencer à encaisser pendant qu'un dossier opérateur avance.
Passez à l'API si vous livrez du numérique qui doit partir immédiatement, si votre volume rend le rapprochement manuel intenable, si plusieurs personnes doivent voir le même état des paiements, ou si votre site doit décider seul d'expédier une commande.
Le critère décisif n'est pas technique, il est opérationnel : qui confirme, et en combien de temps ? Si la réponse peut rester « moi, dans la journée », le code marchand tient. Si elle doit être « le système, en dix secondes », il faut l'API.
Vous n'aurez pas à tout réécrire
C'est le point qui rend l'arbitrage moins lourd qu'il n'y paraît. Les deux modes vivent derrière la même interface : les pilotes — code marchand, MTN, Orange, bac à sable — exposent les mêmes opérations. Le choix se fait par configuration, opérateur par opérateur et mode par mode.
Autrement dit, si vous intégrez aujourd'hui avec le code marchand, votre code crée déjà un paiement, suit un statut et reçoit une notification quand le statut change. Le jour où le contrat opérateur est signé, on bascule le routage. Votre application, elle, ne bouge pas.
Une seule chose doit être prévue dès le départ : le statut « en attente de confirmation » existe. Si votre boutique ne sait gérer que « payé » ou « échoué », elle sera inutilisable en code marchand et fragile en API — parce que ce statut intermédiaire apparaît aussi quand un client tarde à saisir son code.
Notre recommandation
Commencez par le code marchand, mais intégrez comme si vous étiez déjà en API : créez vos paiements par le code, écoutez les notifications, ne livrez jamais sans avoir relu le statut. Vous encaissez dès demain, et le jour de la bascule ne coûte qu'un changement de configuration.