Le problème des paiements en Afrique : pourquoi Stripe ne suffit pas

L'Afrique traite plus de 1 000 milliards de dollars de transactions mobile money par an. Plus de 500 millions de personnes utilisent le mobile money comme instrument financier principal -- non pas comme une alternative aux cartes, mais comme un remplacement de tout un système bancaire qui ne les a jamais atteints. Pourtant, si vous essayez d'accepter un paiement d'un client en Côte d'Ivoire, au Sénégal ou au Cameroun via Stripe, vous découvrirez que la plateforme de paiement la plus populaire au monde ne fonctionne tout simplement pas pour la majeure partie du continent.

C'est le problème des paiements en Afrique. Et c'est la raison principale pour laquelle nous avons construit 0fee.dev.

Les chiffres qui changent tout

Considérez ces données du rapport State of the Industry de la GSMA :

Le contraste est saisissant. Aux États-Unis, plus de 80 % des adultes possèdent une carte de crédit ou de débit. En Afrique subsaharienne, moins de 5 % en ont une. Mais 85 % ont un téléphone mobile, et près de la moitié des adultes ont un compte mobile money actif. L'infrastructure de paiement n'est pas absente -- elle est juste fondamentalement différente.

Comment fonctionne le mobile money

Pour les lecteurs qui ne connaissent pas le mobile money, voici le flux. Il n'a rien en commun avec les paiements par carte.

L'expérience client

1. Le client sélectionne "Payer avec Orange Money" (ou MTN MoMo, Wave, M-Pesa, etc.).
2. Il saisit son numéro de téléphone.
3. Il reçoit une notification USSD push ou STK push sur son téléphone -- un menu textuel simple sur son écran, pas une notification d'application.
4. Il entre son code PIN pour confirmer le paiement.
5. La transaction est réglée. Les deux parties reçoivent une confirmation par SMS.

Il n'y a pas de numéro de carte, pas de CVV, pas de 3D Secure, pas d'adresse de facturation. Toute l'authentification repose sur le numéro de téléphone + le code PIN. Le "compte", c'est la carte SIM elle-même.

Le flux technique

Du point de vue de l'intégration, le mobile money est asynchrone par nature :

1. Marchand -> API fournisseur : initier le paiement (téléphone, montant)
2. Fournisseur -> Opérateur télécom : envoyer USSD/STK push au client
3. Client -> Téléphone : saisir le PIN pour confirmer
4. Opérateur télécom -> Fournisseur : callback de confirmation
5. Fournisseur -> Marchand : notification webhook (succès/échec)

Cela signifie que votre intégration doit gérer :

• La confirmation asynchrone : le client peut prendre 30 secondes ou 5 minutes pour confirmer.
• La gestion des délais d'attente : si le client ne répond pas, la transaction expire (généralement 60-120 secondes pour l'USSD).
• La validation du numéro de téléphone : chaque pays a des formats spécifiques (+225 07XXXXXXXX pour la Côte d'Ivoire, +233 XX XXX XXXX pour le Ghana).
• Les limites de sessions USSD : certains opérateurs limitent les sessions USSD simultanées par numéro de téléphone.

Le paysage des fournisseurs

Aucun fournisseur unique ne couvre toute l'Afrique. Chaque fournisseur a sa propre couverture géographique, ses méthodes de paiement supportées et son intégration technique :

Afrique de l'Est

Afrique de l'Ouest (francophone)

Afrique de l'Ouest (anglophone)

Panafricain

Pour accepter des paiements à travers l'Afrique, vous avez besoin au minimum de trois à quatre intégrations de fournisseurs -- et probablement plus si vous voulez une couverture et une redondance optimales.

La solution 0fee

0fee abstrait toute cette complexité derrière une API unifiée. Chaque méthode de paiement mobile money dans chaque pays suit le même format de requête/réponse :

typescriptimport { ZeroFee } from 'zerofee';

const zf = new ZeroFee({ apiKey: 'zf_live_...' });

// Orange Money en Côte d'Ivoire
const paymentCI = await zf.payments.create({
  amount: 5000,           // 5 000 XOF
  currency: 'XOF',
  country: 'CI',
  method: 'PAYIN_ORANGE_CI',
  customer: { phone: '+2250700112233' },
  returnUrl: 'https://yourapp.com/callback'
});

// MTN MoMo au Ghana
const paymentGH = await zf.payments.create({
  amount: 50_00,          // 50,00 GHS en centimes
  currency: 'GHS',
  country: 'GH',
  method: 'PAYIN_MTN_GH',
  customer: { phone: '+233241234567' },
  returnUrl: 'https://yourapp.com/callback'
});

// M-Pesa au Kenya
const paymentKE = await zf.payments.create({
  amount: 1000_00,        // 1 000,00 KES en centimes
  currency: 'KES',
  country: 'KE',
  method: 'PAYIN_MPESA_KE',
  customer: { phone: '+254712345678' },
  returnUrl: 'https://yourapp.com/callback'
});

Trois pays différents, trois fournisseurs mobile money différents, trois opérateurs télécoms différents -- mais une structure de code identique. Le moteur de routage détermine quel fournisseur sous-jacent utiliser en fonction du pays, de la méthode et des identifiants configurés.

Convention de nommage des méthodes de paiement

Nous avons conçu une convention de nommage systématique pour chaque méthode de paiement du système :

{DIRECTION}_{MÉTHODE}_{PAYS}

PAYIN_ORANGE_CI    = Encaissement via Orange Money en Côte d'Ivoire
PAYIN_MTN_GH       = Encaissement via MTN MoMo au Ghana
PAYIN_MPESA_KE     = Encaissement via M-Pesa au Kenya
PAYIN_WAVE_SN      = Encaissement via Wave au Sénégal
PAYIN_CARD_US      = Encaissement via carte aux États-Unis
PAYOUT_ORANGE_CI   = Décaissement vers Orange Money en Côte d'Ivoire
PAYOUT_BANK_NG     = Décaissement vers compte bancaire au Nigeria

Cette convention rend l'API auto-documentée. Un développeur peut immédiatement comprendre ce que signifie PAYIN_AIRTEL_UG sans lire la documentation : c'est un encaissement via Airtel Money en Ouganda.

La liste complète des méthodes mobile money africaines dans 0fee :

Et ce n'est qu'un sous-ensemble. Le catalogue complet comprend 117 méthodes de paiement couvrant l'Afrique, l'Europe, l'Amérique du Nord, l'Amérique du Sud et l'Asie.

Le problème des webhooks

L'un des aspects les plus pénibles de l'intégration multi-fournisseurs est la gestion des webhooks. Chaque fournisseur envoie des callbacks dans un format différent :

Webhook PawaPay : ``json { "depositId": "dep_abc123", "status": "COMPLETED", "amount": "1000", "currency": "KES", "correspondent": "MPESA_KEN" } ``

Callback Hub2 : ``json { "transaction_id": "txn_xyz789", "statut": "SUCCESS", "montant": 5000, "devise": "XOF", "operateur": "ORANGE_MONEY" } ``

Webhook Paystack : ``json { "event": "charge.success", "data": { "id": 123456, "status": "success", "amount": 50000, "currency": "NGN", "channel": "mobile_money" } } ``

Trois fournisseurs différents, trois noms de champs différents, trois valeurs de statut différentes, trois formats de montants différents. Dans une intégration directe, vous écririez trois gestionnaires de webhooks séparés avec trois pipelines de validation et de normalisation distincts.

0fee normalise tout cela. Votre application reçoit un format de webhook standardisé unique, quel que soit le fournisseur qui a traité le paiement :

json{
  "event": "payment.completed",
  "data": {
    "id": "pay_0fee_abc123",
    "status": "completed",
    "amount": 5000,
    "currency": "XOF",
    "country": "CI",
    "method": "PAYIN_ORANGE_CI",
    "provider": "hub2",
    "customer": {
      "phone": "+2250700112233"
    },
    "metadata": {},
    "created_at": "2026-03-27T10:30:00Z",
    "completed_at": "2026-03-27T10:30:45Z"
  }
}

Un seul gestionnaire de webhooks. Un seul enum de statuts. Un seul format de montant. Chaque fournisseur normalisé selon le même contrat.

OTP et USSD : l'authentification sans cartes

Les paiements par carte utilisent un modèle d'authentification bien compris : numéro de carte, date d'expiration, CVV, et optionnellement 3D Secure. L'authentification mobile money est entièrement différente et varie selon l'opérateur et le pays.

USSD Push (le plus courant en Afrique de l'Ouest) : Le fournisseur envoie une invite USSD au téléphone du client. Le client voit un menu textuel : "Payer 5 000 XOF à [Marchand] ? Entrez votre PIN :" -- cela se passe au niveau de la SIM/opérateur, pas dans une application.

STK Push (M-Pesa, Afrique de l'Est) : Le SIM Toolkit déclenche une invite de paiement directement sur le téléphone. Le client voit un pop-up lui demandant de confirmer le montant et de saisir son PIN M-Pesa.

OTP par SMS (certains fournisseurs) : Le client reçoit un SMS avec un code à usage unique, qu'il saisit sur la page de checkout du marchand. C'est plus proche du 3D Secure mais utilise le SMS au lieu de la page d'authentification de la banque.

Chacun de ces flux a des caractéristiques de délai différentes, des sémantiques de réessai différentes et des modes de défaillance différents. 0fee gère tout cela derrière le même flux de paiement asynchrone : créer le paiement, attendre le webhook, traiter le résultat.

Pourquoi c'est important pour les développeurs africains

Si vous construisez un produit pour les utilisateurs africains, les paiements ne devraient pas être la partie la plus difficile de votre stack. Mais aujourd'hui, un développeur à Abidjan qui veut accepter des paiements Orange Money, MTN MoMo et Wave rien qu'en Côte d'Ivoire doit intégrer au moins deux fournisseurs. Ajoutez le Nigeria et le Kenya, et vous regardez quatre ou cinq intégrations.

0fee réduit tout cela à une seule. Installez le SDK, configurez vos identifiants dans le tableau de bord, et votre page de checkout fonctionne à travers le continent.

bashnpm install zerofee

C'est le seul prérequis d'intégration. Un seul package. Une seule clé API. Cinquante-trois fournisseurs. Deux cents pays. L'Afrique incluse dès le premier jour -- pas comme un ajout tardif.

Cet article fait partie de la série "Comment nous avons construit 0fee.dev". 0fee.dev est un orchestrateur de paiement couvrant 53+ fournisseurs dans 200+ pays, construit par Juste A. GNIMAVO et Claude depuis Abidjan avec zéro ingénieur humain. Suivez la série pour l'histoire complète de la construction.