Encaisser en Afrique. 7 chapitres et un QCM final.

Chapitre 1. Choisir le rail qui porte réellement le marché.

Le rail désigne l'infrastructure qui porte effectivement le volume de paiement d'un marché donné. Il se détermine pays par pays et non région par région, chacun des cinq marchés de ce cours ayant son infrastructure dominante propre. Encaisser en Afrique recouvre donc cinq projets distincts, et non un seul. Le Kenya paie par portefeuille télécom, le Nigeria par virement instantané interbancaire et le Ghana par mobile money interopérable. L'Afrique du Sud paie par carte, et l'UEMOA par portefeuille dans une guerre des prix ouverte. La première décision d'un projet d'encaissement porte sur le rail, avant le choix d'un prestataire.

• Quel rail porte le volume ici ? Pas celui qui a le plus d'articles de presse : celui dont un chiffre primaire récent établit la masse. Au Nigeria, la réponse n'est pas « le mobile money », c'est NIP.
• Mon client peut-il l'utiliser sans changer d'habitude ? Un rail qui suppose une application, un smartphone ou un compte bancaire exclut mécaniquement une part de la base ; quantifiez-la avant de choisir.
• Combien de temps pour être opérationnel ? Un compte marchand chez un émetteur, un raccordement à un switch national et un contrat d'acquisition carte n'ont pas les mêmes délais. Le rail le plus efficace n'est pas toujours celui qu'on peut ouvrir ce trimestre.
• Qui me règle, en quelle monnaie, et sous combien de jours ? C'est la question qui départage deux rails d'apparence équivalente, et celle que l'on oublie le plus souvent au moment de la comparaison.

Chapitre 2. Câbler un encaissement mobile money.

Câbler un encaissement mobile money consiste à relier le système du marchand à celui de l'émetteur du portefeuille, de l'initiation du paiement jusqu'à sa réconciliation. L'opération se ramène à quatre décisions, prises dans cet ordre : quel identifiant marchand est obtenu à l'ouverture de compte, qui initie la transaction, comment le marchand apprend qu'elle a réussi, et contre quoi elle est rapprochée. Les trois dernières relèvent de la technique. La première est contractuelle, se prend des semaines avant le code et verrouille tout le reste.

ETATS AUTORISES
  initie -> en_attente -> { reussi | echoue | indetermine }
  indetermine -> { reussi | echoue }        par interrogation ou releve
  indetermine -> indetermine                tant que rien ne tranche : C'EST LEGITIME

REGLE 1 : l'absence de notification n'est PAS un echec
  ne jamais basculer en "echoue" sur expiration d'un minuteur seul
  un paiement peut avoir debite le client sans que vous soyez notifie

REGLE 2 : idempotence sur l'identifiant de l'emetteur
  cle = (emetteur, pays, identifiant_transaction_emetteur)
  deuxieme notification portant la meme cle -> ignoree, journalisee, 200 OK
  repondre lentement a une notification, c'est provoquer un renvoi

REGLE 3 : boucle d'interrogation bornee, pas infinie
  t+20s, t+60s, t+180s, t+600s puis arret
  au-dela, l'etat se tranche a la reconciliation, pas par un appel de plus

REGLE 4 : ne jamais rapprocher sur le montant
  montant, horodatage et numero du payeur ne sont PAS discriminants :
  un meme client paie deux fois le meme montant dans la meme minute
  plus souvent qu'on ne l'imagine

REGLE 5 : conserver l'identifiant de l'emetteur, toujours
  c'est la seule piece opposable si vous demandez un "reversal" :
  il n'existe pas de chargeback au sens carte sur ces rails

• Répondez à la notification en moins d'une seconde, et traitez ensuite. Accusez réception, mettez en file, travaillez en asynchrone. Un traitement métier lourd exécuté dans le gestionnaire de notification déclenche des renvois, donc des doublons.
• Stockez le montant dans la devise locale, jamais converti. KES, NGN, GHS, ZAR, XOF sont les seules valeurs opposables. Une base qui ne stocke que l'équivalent en euros ou en dollars rend toute réconciliation impossible et toute demande de correction indéfendable.
• Masquez le numéro du payeur en stockage. Sur ces rails, le numéro de téléphone est l'identifiant de paiement : il se traite avec le même soin qu'un numéro de carte.
• Prévoyez la file des paiements non appariés dès la version 1. Sur un encaissement à référence saisie par le client, elle se remplira dès la première semaine. La question n'est pas de l'éviter mais de savoir qui la traite, en combien de temps, et avec quel écran.
• Testez le rejeu. Renvoyez-vous à vous-même une notification déjà traitée, en recette comme en production surveillée : si un deuxième exemplaire de la commande part, votre idempotence est décorative.

Chapitre 3. USSD : concevoir le parcours sans smartphone.

L'USSD est un canal de dialogue par menus textuels, ouvert depuis un téléphone quelconque par la composition d'un code court et sans connexion de données. Il porte encore une part décisive des encaissements sur ces marchés. Le canal est synchrone, sans état côté combiné, à écran contraint et facturé à la session. Ces quatre propriétés séparent l'USSD d'une application mobile, qui conserve son état entre deux écrans et tolère l'attente. Un parcours conçu selon les règles d'une application aboutit à des sessions qui expirent au moment de payer. Ce chapitre traite de la conception du parcours d'encaissement, non de la technologie du canal.

• Le budget de latence est votre contrat technique. Une session USSD expire (de l'ordre de 20 à 180 secondes selon l'opérateur). Tout appel externe lent placé dans le chemin de la session la tue. Règle : réponse immédiate, confirmation asynchrone, jamais d'appel bloquant vers votre back-office.
• Chaque écran coûte deux fois. Il est facturé par l'opérateur, souvent à la session ou à l'écran, et il ajoute un point d'abandon. Un parcours à sept écrans n'est pas « plus complet » qu'un parcours à trois : il est plus cher et il convertit moins.
• L'écran tient dans environ 182 caractères. Ce n'est pas une contrainte de mise en page, c'est une contrainte de rédaction : le libellé du montant et le nom du bénéficiaire doivent y tenir sans être tronqués, dans la langue locale.
• Le code court est un actif réglementé et rare. Il est attribué par l'autorité de communications électroniques du pays, pas par l'opérateur mobile money : obtenir le sien suppose un dossier et des délais qui se comptent en mois. Dans la plupart des projets, on utilise donc le code de l'émetteur ou celui de l'agrégateur ; décidez-le au cadrage, pas à la recette.
• Les codes diffèrent par pays chez un même opérateur. MTN MoMo s'ouvre par *170# au Ghana, *165# en Ouganda, *133# en Côte d'Ivoire, *126# au Cameroun, *182# au Rwanda, *671# pour MoMo PSB au Nigeria ; M-PESA par *334# au Kenya (codes publiés par les opérateurs, 2026, à revérifier auprès de la filiale locale avant toute impression sur un support client : ils changent).
• Le canal n'est pas chiffré de bout en bout. Le code secret protège l'opération, pas la confidentialité du transport. Rien de sensible ne transite en clair dans un menu, et surtout aucun élément qui permettrait de rejouer une opération.

BUDGET D'UNE SESSION (a poser AVANT d'ecrire le premier ecran)

  duree utile de session      20 a 180 s selon l'operateur (hypothese basse : 20 s)
  temps de lecture + saisie   ~6 a 10 s par ecran cote client
  => 3 ecrans consomment deja l'essentiel d'une session courte

  ce que votre back-office a le droit de consommer :  < 1 s par ecran
  ce qu'il n'a PAS le droit de faire dans la session :
      - interroger un service tiers sans minuteur strict
      - calculer un prix, verifier un stock, appeler un ERP
      - attendre la confirmation definitive du paiement

CONCEPTION CIBLE : trois ecrans, zero saisie de reference

  ecran 1   confirmer l'objet et le montant        "Payer 2 500 a NOM ? 1=Oui 2=Non"
  ecran 2   code secret                            gere par la plateforme de l'emetteur
  ecran 3   accuse de reception                    "Demande envoyee. SMS de confirmation."
            -> l'etat definitif arrive par notification serveur, PAS dans la session

CE QUI FAIT ECHOUER LES PARCOURS, PAR FREQUENCE DECROISSANTE
  1. saisie d'une reference de commande par le client        -> faute de frappe
  2. appel synchrone vers un systeme interne lent            -> session expiree
  3. libelle tronque a l'ecran                               -> abandon par doute
  4. montant recalcule apres l'ecran 1                       -> incoherence percue
  5. livraison declenchee sur l'ecran 3                      -> livraison sans paiement

Chapitre 4. Cartes domestiques, rails A2A et paiement récurrent.

Un scheme carte domestique est un réseau de cartes dont les règles et la marque relèvent d'un acteur de la zone où il opère. Un rail de virement de compte à compte, désigné A2A, transporte un crédit poussé par le payeur depuis son compte vers celui du bénéficiaire. À côté du portefeuille, chacun de ces cinq marchés a construit ses propres instruments dans ces deux familles. L'Afrique du Sud y ajoute un régime de prélèvement parmi les plus élaborés du continent. Ce chapitre expose ce que chacun permet et ce qu'il interdit. La plupart des refus inexpliqués rencontrés en production viennent d'une mauvaise attribution de rôle entre ces instruments.

• Une carte domestique ne franchit pas la frontière. AfriGO est conçu pour que la transaction reste dans le pays ; gh-link, e-zwich et GIM-UEMOA sont des schemes de zone. Un abonnement facturé depuis une entité étrangère sur une de ces cartes échouera, et le refus ne sera pas explicite. Si votre modèle est un prélèvement international récurrent, ces cartes ne sont pas votre instrument.
• Le co-badgeage change le coût, pas seulement l'acceptation. Là où une carte porte à la fois un scheme domestique et un scheme international, le routage décide de l'interchange payé. C'est un paramètre d'acquisition à négocier explicitement, pas un réglage technique par défaut.
• Le rail instantané n'a pas d'autorisation à deux temps. Ni pré-autorisation, ni capture différée, ni annulation : le crédit est poussé, immédiat et définitif. Tout modèle commercial fondé sur une empreinte puis un débit ultérieur (caution, réservation, ajustement de montant) doit être repensé, pas transposé.
• Le plafond est un paramètre produit. 50 000 GHS par transaction sur GIP au Ghana ; des plafonds par palier de connaissance client sur les portefeuilles, qui varient par pays, par palier et parfois par canal. Un panier moyen élevé peut être structurellement inencaissable sur le rail que vous avez choisi : vérifiez-le avant l'intégration, pas après.
• Un instrument peut être en production sans être utilisé. GhQR est techniquement déployé depuis 2020 et commercialement décevant ; l'eNaira est toujours en service et son adoption a été publiquement reconnue comme faible par la CBN en novembre 2025. « Disponible » et « utilisé » sont deux qualifications distinctes, et seule la seconde intéresse un plan d'encaissement.

Chapitre 5. Agrégateur ou direct : choisir, et calculer le coût complet.

Trois chemins mènent à l'encaissement sur ces marchés. Le premier consiste à contracter directement avec chaque émetteur et chaque acquéreur. Le deuxième passe par une passerelle domestique qui les a déjà tous ouverts dans un pays. Le troisième passe par un agrégateur panafricain qui couvre plusieurs pays sous un seul contrat. Le choix relève du délai d'ouverture, de la chaîne de responsabilité et du coût complet, plutôt que des caractéristiques techniques de l'intégration. Ce coût complet dépasse la commission affichée, qui n'en est qu'un poste parmi six, aux côtés des frais et du délai de règlement, du change, de la taxe sur les transactions et du coût d'échec et de litige.

LES SIX POSTES. Les cinq derniers sont ceux qu'on oublie.

  1. COMMISSION D'ENCAISSEMENT      % du montant, + part fixe, souvent par palier
                                    et par instrument (wallet != carte != virement)
  2. FRAIS DE REGLEMENT             sortie du compte marchand vers un compte
                                    bancaire local -- facture separement, par
                                    virement ou par lot
  3. DELAI DE REGLEMENT             J+0 en monnaie electronique, souvent J+1/J+2
                                    vers la banque. Cout = tresorerie immobilisee
  4. CHANGE                         ecart au taux interbancaire, PAS la commission
                                    affichee. Se mesure, ne se demande pas
  5. TAXE SUR LES TRANSACTIONS      poste politique, variable, revisable chaque
                                    loi de finances (voir chapitre 6)
  6. COUT D'ECHEC ET DE LITIGE      paiements non apparies a rattacher a la main,
                                    "reversals" a instruire, support de 1er niveau

EXEMPLE DE CALCUL -- LES TAUX SONT DES PARAMETRES D'EXEMPLE,
PAS DES TARIFS CONSTATES : remplacez-les par VOTRE grille negociee.

  Panier                                        10 000 (monnaie locale)
  Commission d'encaissement    hypothese 1,80 %      180
  Part fixe                    hypothese               20
  Frais de reglement           hypothese, amorti        8
  Cout du delai J+2            hypothese                3
  Ecart de change au rapatriement  hypothese 1,20 %   120
  Taxe sur transaction         selon le pays            0
  Provision echec/rattachement hypothese 0,40 %        40
  ------------------------------------------------------------
  COUT COMPLET                                         371  = 3,71 %
  COMMISSION AFFICHEE                                  180  = 1,80 %

  >>> LE RATIO ENTRE CES DEUX LIGNES EST LE SEUL CHIFFRE
      QUI PERMETTE DE COMPARER DEUX OFFRES.

CE QU'IL FAUT EXIGER POUR REMPLIR LA GRILLE
  - une simulation sur VOTRE mix reel (instrument, montant, pays, mois)
  - le taux de change applique sur un montant temoin, un jour donne,
    compare au taux interbancaire du meme jour
  - la grille de reglement : frequence, seuil minimal, frais par virement
  - le taux de paiements non apparies constate sur des marchands comparables

• Qui détient mon argent entre l'encaissement et le règlement, et sous quel agrément ? La réponse doit nommer une entité et son statut, pas une marque commerciale.
• Quel est le délai de règlement contractuel, par instrument, et quelles sont les causes de suspension ? C'est le premier poste à négocier, avant même la commission.
• Dans quelle devise suis-je réglé, et qui fixe le taux ? Un règlement en devise locale et une conversion opérée par vous n'ont pas le même coût qu'un règlement converti par le prestataire.
• Quelle est la couverture réelle par émetteur, dans ce pays précis ? Un agrégateur « présent au Ghana » peut n'y couvrir qu'un émetteur sur trois.
• Que se passe-t-il quand un paiement arrive sans référence exploitable ? Existe-t-il un écran, une API de rattachement, un délai de conservation ?
• *Comment demande-t-on un reversal, sous quel délai, avec quel taux de succès constaté ? Il n'existe pas de schéma de litige standardisé sur ces rails : la procédure du prestataire est* votre seul recours.
• Quel est le mécanisme de rapprochement quotidien fourni ? Un relevé exploitable par machine, ou un export à retraiter ?
• Quels plafonds s'appliquent, par transaction, par jour, par palier de connaissance client ? Et comment suis-je notifié quand ils changent ?
• Quelle est la réversibilité ? Portabilité des identifiants marchands, export de l'historique, préavis. Le coût de sortie se négocie à l'entrée.
• Quels chiffres m'avez-vous donnés qui soient audités ? Voir l'avertissement ci-dessous.

Chapitre 6. Licences e-money, change, rapatriement et PAPSS.

Deux qualifications décident de la faisabilité d'un projet d'encaissement sur ces marchés. L'une comme l'autre précède le premier appel d'API. La première porte sur le régime d'agrément, selon que le marchand a besoin d'un agrément propre ou encaisse sous celui d'un tiers. La seconde porte sur la sortie des fonds, par quel chemin ils quittent le pays, à quel taux et sous quel délai. Les entreprises qui traitent cette seconde question après la mise en production constatent, dans le meilleur des cas, que leur marge part en change.

• Instruisez le rapatriement avant la signature, jamais après le premier mois. Les questions sont : quelle banque locale, quels justificatifs par virement sortant, quel délai constaté, quelle disponibilité de devise forte, et quelles autorisations préalables. Ces réponses conditionnent votre modèle de trésorerie, pas seulement votre comptabilité.
• La taxe sur les transactions est le risque politique n° 1 de la région, et il se modélise. Le Ghana a introduit un e-levy en mai 2022 à 1,5 % au-delà d'un seuil d'exonération de 100 cedis par jour, ramené à 1 % en janvier 2023 ; les valeurs mobile money ont reculé d'environ 12 % dans les six mois suivant l'entrée en vigueur (Bank of Ghana), avant l'abrogation votée le 26 mars 2025 et effective le 2 avril 2025. Le Cameroun prélève 0,2 % à l'envoi comme au retrait depuis la loi de finances 2022, alourdi d'un forfait de 4 FCFA en 2025 ; l'Ouganda taxe les retraits à 0,5 %. Toute prévision de revenus sur ces marchés doit porter un scénario fiscal.
• Dans une union monétaire, « transfrontalier » ne veut pas dire ce que vous croyez. Entre deux pays de l'UEMOA, le paiement est techniquement domestique : SICA-UEMOA pour la compensation et STAR-UEMOA pour le règlement opèrent depuis 2004 sous la BCEAO, et GIM-UEMOA couvre la carte sur les huit pays. Un flux Abidjan–Dakar ne pose pas le problème de change d'un flux Abidjan–Accra.
• Le mobile money est l'instrument d'origination le moins cher pour recevoir de l'argent. Un envoi de 200 $ vers l'Afrique subsaharienne coûtait 8,78 % en moyenne au T1 2025, contre 6,49 % de moyenne mondiale, mais 3,63 % quand l'origination se fait par mobile money, et 9,50 % quand elle passe par une banque (Banque mondiale, Remittance Prices Worldwide, T1 2025). C'est la raison économique pour laquelle tous les corridors convergent vers le portefeuille.

Chapitre 7. Recette, fraude et exploitation quotidienne.

Un mode de défaillance désigne une manière dont un encaissement échoue ou se corrompt en exploitation. Sur ces marchés, ces modes diffèrent de ceux d'un marché carte, où le litige suit un schéma à cycles, un arbitrage réseau et des règles de représentation. Aucun de ces trois mécanismes n'existe ici. La correction d'un paiement erroné passe par une procédure de *reversal opérée par l'émetteur, sur demande, avec un délai et un taux de succès très variables. Le contrôle est donc en amont*, la recette devant tester les défaillances locales et non le chemin nominal.

CHAQUE JOUR, DANS CET ORDRE

  1. RECUPERER le releve de l'emetteur / du prestataire pour J-1
     -> source de verite. Votre journal applicatif ne l'est PAS

  2. APPARIER sur l'identifiant de transaction de l'emetteur
     jamais sur (montant, heure, numero) : non discriminant

  3. CLASSER les ecarts en QUATRE familles, chacune avec un traitement
     a. chez l'emetteur, absent chez moi   -> notification perdue :
                                              creer, livrer, alerter
     b. chez moi, absent chez l'emetteur   -> etat fantome :
                                              annuler, NE PAS livrer
     c. montants divergents                -> frais non modelises,
                                              ou mauvais palier
     d. non apparies (sans reference)      -> file de rattachement,
                                              propriétaire nomme, delai

  4. RAPPROCHER le reglement bancaire recu du brut encaisse J-2/J-3
     brut encaisse - commissions - frais de reglement - taxe = net attendu
     tout ecart inexplique se conteste dans la fenetre contractuelle,
     qui est courte

  5. PUBLIER trois indicateurs, tous les jours, aux memes personnes
     - taux d'etats indetermines residuels a J+1
     - age du plus vieux non-apparie
     - ecart net attendu / net recu, en devise LOCALE

CE QUI DOIT DECLENCHER UNE ALERTE, PAS UN TICKET
  - un etat indetermine de plus de 24 h
  - un reglement bancaire absent a la date contractuelle
  - un ecart de frais qui se repete deux jours de suite