PrestaShop et paiement mobile money : guide pratique

Lecture : 13 minutes · Niveau : intermédiaire · Mise à jour : avril 2026

L’enjeu critique pour toute boutique PrestaShop en Afrique de l’Ouest : encaisser via mobile money. Wave, Orange Money, MTN Money sont incontournables. Ce guide détaille les approches techniques pour les intégrer à PrestaShop, dans une perspective PME pragmatique.

Voir aussi → PrestaShop pour PME francophones : guide complet et l’article équivalent pour Shopify et paiement mobile money.

Sommaire

1. Contexte mobile money en AO et PrestaShop
2. Quatre approches d’intégration
3. Approche 1 : module agrégateur
4. Approche 2 : module dédié par opérateur
5. Approche 3 : Cash on Delivery natif
6. Approche 4 : module custom via API
7. Configuration et tests
8. Réconciliation comptable
9. Sécurité et protection contre la fraude
10. Bonnes pratiques opérationnelles
11. FAQ

1. Contexte mobile money en AO et PrestaShop

Le constat

Dans plusieurs pays UEMOA, le mobile money représente une part majoritaire des paiements digitaux des particuliers. Une boutique PrestaShop qui ne propose que cartes bancaires et virement laisse passer une part significative des conversions.

Les opérateurs majeurs

• Wave (Sénégal, Côte d’Ivoire) : très populaire, frais réputés bas
• Orange Money : présent dans la plupart des pays AO
• MTN Mobile Money : Côte d’Ivoire, Cameroun, Ghana, Bénin
• YAS Money (ex-Free Money) (Sénégal), Moov Money, Wizall : opérateurs secondaires

PrestaShop natif vs modules tiers

PrestaShop ne propose pas de module mobile money natif (Wave, OM ne sont pas des moyens de paiement standard internationaux comme Stripe). L’intégration passe donc par des modules tiers : agrégateurs, modules d’éditeurs spécialisés AO, ou développement custom.

2. Quatre approches d’intégration

La combinaison la plus courante : module agrégateur + COD activés en parallèle. Couvre la quasi-totalité des préférences clients.

3. Approche 1 : module agrégateur

Principaux agrégateurs

• PayDunya : couvre Sénégal, Côte d’Ivoire, autres pays UEMOA. Module PrestaShop disponible.
• CinetPay : focus Côte d’Ivoire, multi-pays AO. Module PrestaShop officiel.
• Flutterwave : pan-africain, plus orienté Nigeria/Ghana mais présent en AO. Modules disponibles.
• HUB2 : agrégateur multi-pays, modules disponibles selon distributeurs.

Workflow type

1. Vous ouvrez un compte merchant chez l’agrégateur (KYC complet : RCCM, NINEA, justificatifs)
2. Téléchargez le module PrestaShop depuis le site agrégateur ou Addons
3. Installez le module dans Modules → Charger un module
4. Configurez avec votre API key et secret
5. À la commande, le client clique « Payer par mobile money »
6. Redirection vers la page agrégateur, choix de l’opérateur (Wave, OM, etc.)
7. Paiement effectué côté opérateur
8. Webhook agrégateur → PrestaShop marque la commande payée
9. Email de confirmation au client, mise à jour du stock

Avantages

• Couverture multi-opérateurs en une seule intégration
• Notification automatique dans PrestaShop
• Tableau de bord unique pour suivi
• Pas de développement : install et configure

Inconvénients

• Commission agrégateur s’ajoute aux frais opérateur
• Délai de KYC initial (jours à semaines selon agrégateur)
• Délai de versement vers banque (variable, à anticiper en trésorerie)
• Dépendance à un tiers : panne agrégateur = paiements bloqués

Choisir un agrégateur

• Couverture des opérateurs dans votre zone
• Grille tarifaire complète (commission, frais retrait)
• Qualité du module PrestaShop (avis, mises à jour)
• SLA et réactivité du support
• Délais de versement
• Réputation auprès d’autres marchands AO (réseau / communauté)

Tester en mode sandbox avant de basculer en production.

4. Approche 2 : module dédié par opérateur

Quelques modules PrestaShop ciblent un opérateur spécifique : Wave seul, OM seul.

Avantages

• Pas de commission agrégateur : seuls les frais opérateur s’appliquent
• Latence potentiellement plus faible
• Relation directe avec l’opérateur

Inconvénients

• Une intégration par opérateur : Wave + OM = 2 modules à gérer
• Qualité variable : certains modules sont peu maintenus
• Disponibilité limitée : tous les opérateurs n’ont pas de module PrestaShop maintenu
• Conditions commerciales : compte merchant agréé requis directement avec l’opérateur

Quand pertinent

Si la quasi-totalité de vos clients utilisent UN opérateur (cas fréquent au Sénégal avec Wave, par exemple), passer par un module dédié peut être plus rentable et plus simple. Pour deux opérateurs ou plus : agrégateur reste plus simple.

Évaluation d’un module dédié

• Compatibilité version PrestaShop
• Date de dernière mise à jour
• Avis utilisateurs récents
• Support actif de l’éditeur
• Conditions commerciales claires (achat unique vs abonnement)

5. Approche 3 : Cash on Delivery natif

PrestaShop propose un module COD natif (« Paiement à la livraison ») dans son installation par défaut. Très utilisé en AO.

Configuration

Modules → Module Manager → rechercher "Cash on Delivery" → Configurer

Activer, configurer le mode (espèces uniquement, mobile money à la livraison via terminal du livreur, etc.), définir les zones où c’est disponible.

Avantages

• Aucun coût technique ni commission
• Confiance client : payer après avoir vu le produit rassure beaucoup en AO
• Conversion souvent plus haute que paiement pré-paid pour boutiques nouvelles
• Inclusion : touche les clients sans paiement digital facile

Inconvénients

• Risque de commande fantôme : commande sans intention réelle d’achat
• Trésorerie immobilisée : expédition sans encaissement préalable
• Coûts de retour : livraison non prise = retour à votre charge
• Manipulation d’espèces : risque sécurité

Discipline opérationnelle pour COD

• Confirmation téléphonique systématique avant expédition (appel ou WhatsApp)
• Acompte mobile money : par exemple 30 % en mobile money + reste en COD
• Blacklist des numéros qui ont annulé plusieurs fois
• Limite géographique : COD uniquement dans zones où la livraison fonctionne bien
• Tracking SMS/WhatsApp pour réduire les surprises côté client
• Limite de montant : COD plafonné pour éviter les pertes massives en cas d’abandon

COD + mobile money à la livraison

Certains transporteurs urbains (livreurs avec smartphone) permettent l’encaissement mobile money à la remise du colis. Combine la confiance du COD avec un encaissement digital instantané. À explorer avec votre transporteur.

6. Approche 4 : module custom via API

Pour des besoins spécifiques que les modules existants ne couvrent pas.

Quand justifié

• Volume très important (milliers de transactions/jour)
• Besoins métier très spécifiques (split payments, escrow, abonnements complexes)
• Multi-opérateurs avec logique business propre
• Ressource développeur PHP / PrestaShop disponible
• Volonté de contrôle total

Composants techniques

• Module PrestaShop classique avec hooks de paiement
• Appels API au fournisseur (HTTP via cURL ou Guzzle)
• Webhook handler pour notifications de paiement
• Vérification de signature des webhooks
• Logging détaillé pour debug
• Gestion des erreurs et retries

Bonnes pratiques

• Idempotence : un webhook reçu 2 fois ne crée pas 2 paiements
• Vérification signature : tout webhook doit être signé par l’opérateur
• Logs complets : timestamp, payload, signature, résultat
• Mode sandbox : tester en intégral avant production
• Gestion des cas limites : timeouts, paiements partiels, doubles paiements, remboursements

Coût et délai

Compter typiquement 10-25 jours-homme pour une intégration robuste avec un opérateur, plus tests et déploiement. Investissement à amortir sur le long terme.

7. Configuration et tests

Préparation

Avant tout :
– Compte merchant chez l’opérateur ou agrégateur, KYC validé
– API key et secret en main
– URL de webhook configurée côté fournisseur (PrestaShop expose des callbacks)
– HTTPS strict actif sur PrestaShop

Installation

Admin PrestaShop → Modules → Charger un module → Sélectionner le ZIP
→ Installer → Configurer

Renseigner les credentials, choisir les opérateurs activés, configurer les URL de retour (succès/échec/annulation).

Tests pré-production

Toujours tester sur des comptes ou montants minimaux :

1. Commander en tant que client de test
2. Choisir le moyen de paiement mobile money
3. Vérifier la redirection
4. Effectuer le paiement réel (petit montant : 100-500 FCFA)
5. Vérifier que le webhook arrive bien
6. Vérifier que la commande passe au statut payé
7. Vérifier l’email de confirmation

Tests d’échec

Tester aussi les cas :
– Paiement refusé par l’opérateur
– Annulation par le client
– Timeout
– Webhook qui n’arrive pas (simuler en bloquant temporairement)

Documenter le comportement attendu dans chaque cas.

8. Réconciliation comptable

L’intégration technique ne suffit pas. La conciliation comptable demande de la rigueur.

Le défi

Mobile money n’est pas un compte bancaire. Les fonds arrivent sur le compte mobile money merchant, qui doit ensuite faire des retraits vers le compte bancaire ou utiliser directement les fonds.

Workflow comptable

1. Export quotidien des commandes payées de PrestaShop
2. Vérification croisée avec compte agrégateur ou comptes mobile money
3. Identification des écarts (rare mais possible : commande marquée payée mais paiement en réalité échoué)
4. Saisie comptable dans le logiciel comptable (Odoo idéalement, voir Odoo et paiement mobile money)
5. Reconnaissance mensuelle des frais agrégateur en charges
6. Réconciliation avec les retraits vers banque

Outils

• Module export comptable : export CSV adapté à votre logiciel comptable
• Intégration directe PrestaShop ↔ Odoo : modules de sync existent
• Tableau Excel + cabinet comptable : suffit pour démarrer

Points de vigilance

• Conserver tous les justificatifs de transactions (logs, screenshots si demandés)
• Réconciliation au moins hebdomadaire pour ne pas accumuler les écarts
• Trace des remboursements (mobile money permet variablement les remboursements directs)

9. Sécurité et protection contre la fraude

Risques spécifiques

• Faux paiements : client envoie une capture « payé » alors que ça n’a pas eu lieu côté opérateur. Toujours vérifier dans votre back-office, jamais sur la base d’un screenshot.
• Chargebacks : moins fréquents qu’en cartes, mais possibles via certains agrégateurs
• COD abusif : commandes répétées non récupérées par le même numéro
• Fraude carte : commandes test à 1 FCFA puis montant croissant

Bonnes pratiques

• Vérification téléphonique systématique pour commandes > seuil
• Blacklist numéros / adresses problématiques
• Limites par client : nouveau client = limite plus basse
• 3D Secure activé sur les paiements carte quand disponible
• Surveillance des patterns : commandes suspectes (montants anormaux, adresses incohérentes, multiples adresses email)

En cas de litige

• Conservation des échanges WhatsApp/email
• Preuves de livraison signées
• Confirmation tracking transporteur
• Logs de la transaction mobile money

Documentation systématique = arme principale en cas de chargeback ou contestation.

10. Bonnes pratiques opérationnelles

Communication client

• Page « Moyens de paiement acceptés » claire et bien visible
• Logos des opérateurs sur la home et footer (rassure)
• FAQ paiement (comment payer, quand on est débité, sécurité)
• Confirmation de commande avec statut paiement clair

Frais transparents

• Si vous facturez au client les frais de paiement : afficher clairement
• Si vous absorbez les frais : c’est un coût de votre marge, à intégrer dans la stratégie de prix

Multiples méthodes

Proposer 3-4 méthodes (carte, mobile money agrégateur, COD, virement) couvre la grande majorité des préférences. Permettre au client de choisir.

Suivi quotidien

• Dashboard agrégateur consulté quotidiennement
• Alertes sur paiements en attente, échecs récurrents, erreurs API
• Réponse rapide aux incidents pour préserver la confiance client

Évolution dans le temps

• Au démarrage : peu de moyens, simple à gérer
• Croissance : ajouter méthodes selon demande client réelle
• Maturité : optimiser frais, éventuellement passer à intégration custom si volume justifie

11. FAQ

Quel module agrégateur recommandé pour le Sénégal ?

PayDunya et CinetPay sont parmi les plus utilisés en zone UEMOA avec couverture Wave, Orange Money. Tester chacun en mode sandbox, comparer grilles tarifaires et SLA avant engagement.

Le COD est-il vraiment fiable en Côte d’Ivoire ?

Oui avec discipline opérationnelle (confirmation téléphonique, acompte, blacklist). Sans discipline : taux d’échec élevé. La logistique locale et la zone de livraison comptent autant que le module.

Combien de temps pour intégrer un module agrégateur ?

Quelques heures pour l’installation et la configuration de base, plus quelques jours pour les tests en sandbox et la production. KYC initial peut prendre 1-2 semaines selon l’agrégateur.

Faut-il proposer carte ET mobile money ?

Oui idéalement. Une partie des clients préfère la carte (plus d’anonymat perçu), une autre préfère mobile money (plus simple, pas besoin de saisir de carte). Couvrir les deux maximise les conversions.

Que faire si l’agrégateur tombe en panne ?

Avoir au moins une méthode de paiement de secours active (COD, ou un second moyen de paiement). Communiquer à l’agrégateur et aux clients en cas d’incident prolongé.

Remboursement mobile money via PrestaShop : faisable ?

Variable selon agrégateur. Wave permet de rembourser via API. Orange Money est plus restrictif. Beaucoup de marchands proposent des avoirs/bons d’achat plutôt que remboursements directs pour simplifier.

Comment gérer les commandes payées partiellement ?

PrestaShop ne gère pas nativement les paiements multiples sur une commande. Workaround : créer plusieurs commandes liées par référence, ou utiliser un module dédié multi-paiements.

Articles liés (cluster PrestaShop)

• 👉 PrestaShop pour PME francophones : guide complet (pillar)
• 👉 PrestaShop modules essentiels
• 👉 PrestaShop performance et SEO

Article mis à jour le 25 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.