Sécuriser les paiements en ligne au Sénégal : fraude, 3-D Secure et tokenisation en 2026

La première fois qu'un marchand sénégalais découvre la fraude, c'est rarement par une grosse perte spectaculaire. C'est par une série de petites commandes payées par carte étrangère, livrées, puis rejetées quelques semaines plus tard par la banque émettrice. Le marchand à expédie la marchandise, encaisse en apparence, puis reçoit un débit de son agrégateur qui lui reprend l'argent. C'est le scénario classique du chargeback, et il fait mal parce qu'il arrive à retardement, sur une vente qu'on croyait acquise.

Au Sénégal, la réalité de la fraude est double. D'un côté le mobile money (Wave, Orange Money, Free Money) où il n'existe pas de chargeback, mais où la fraude prend la forme d'ingénierie sociale, de faux justificatifs et d'arnaques au remboursement. De l'autre la carte bancaire (Visa, Mastercard via PayDunya, CinetPay, Hub2 ou un PSP international), où la fraude classique aux numéros volés et le chargeback existent bel et bien. Sécuriser ses paiements, ce n'est donc pas appliquer une recette unique : c'est comprendre quel canal porte quel risque et y mettre la bonne défense.

Cet article décrit les types de fraude que nous voyons concrètement chez nos clients e-commerce au Sénégal, puis les mécanismes techniques qui les contrent : 3-D Secure, tokenisation, OTP mobile money, vérification des signatures de webhook, et le périmètre PCI-DSS quand on touche à la carte. L'objectif n'est pas la paranoia, mais un niveau de protection proportionné au volume et au panier moyen.

Les types de fraude réels au Sénégal

Avant de parler outils, il faut nommer l'ennemi. Voici ce que nous rencontrons le plus souvent.

• Fraude à la carte volée (carding) : un attaquant testé des numéros de carte volés sur votre site, souvent par petits montants pour valider que la carte fonctionne. Vous voyez une rafale de tentatives, beaucoup d'échecs, quelques succès. Les cartes étant étrangères, le chargeback suit.
• Chargeback abusif (friendly fraud) : le client a bien reçu le produit mais conteste le débit auprès de sa banque. Sans 3-D Secure, c'est le marchand qui perd. Avec 3-D Secure, la responsabilité bascule souvent vers l'émetteur.
• Ingénierie sociale mobile money : un faux acheteur envoie une fausse capture d'écran de paiement Wave ou Orange Money, ou prétend avoir payé en trop et demande un remboursement de la différence. La capture est truquée, le paiement initial n'existe pas.
• Arnaque au remboursement : le fraudeur paie réellement, reçoit le bien, puis ouvre un litige auprès de l'opérateur en pretendant ne pas avoir reçu, ou paie depuis un compte lui-même volé.
• Account takeover : prise de contrôle d'un compte client (mot de passe réutilisé, OTP intercepte) pour passer des commandes ou changer l'adresse de livraison.
• Fraude interne : un employé crée de faux remboursements vers son propre numéro. C'est sous-estimé et pourtant fréquent dans les petites structures sans séparation des rôles.

Le point clé : sur mobile money, la défense est surtout procédurale (ne jamais se fier à une capture, toujours vérifier la transaction côté opérateur ou via le webhook signé). Sur carte, la défense est surtout technique (3-D Secure, scoring, tokenisation).

3-D Secure : faire basculer la responsabilité

Le 3-D Secure (Verified by Visa, Mastercard Identity Check) ajoute une étape d'authentification forte côté porteur : OTP envoyé par la banque émettrice, ou validation dans l'application bancaire. Pour le marchand, l'intérêt n'est pas seulement de bloquer des fraudeurs, c'est le liability shift : sur une transaction authentifiée en 3DS, en cas de contestation pour fraude, c'est généralement la banque émettrice qui supporte la perte, pas le marchand.

En pratique au Sénégal, la quasi-totalité des PSP qui acceptent la carte (PayDunya, CinetPay, Hub2, Paystack, Stripe pour ceux qui ont une entité hors zone) proposent ou imposent le 3DS2. Recommandations concrètes :

• Activez le 3DS sur 100 pour cent des transactions carte, même si le taux d'abandon monte légèrement. Le coût d'un chargeback (montant + frais de 5 000 à 15 000 FCFA selon le PSP + impact sur votre taux de litige) dépasse largement la marge perdue sur quelques abandons.
• Surveillez votre taux de chargeback. Au-delà de 1 pour cent des transactions, les réseaux peuvent vous placer en programme de surveillance, ce qui menace votre contrat marchand.
• Utilisez le 3DS2 (et non l'ancien 3DS1) : il fait du scoring de risque et évite l'OTP quand la transaction est jugée sûre (frictionless flow), ce qui améliore la conversion.

Tokenisation : ne jamais stocker un numéro de carte

La tokenisation remplace le numéro de carte (PAN) par un jeton inutilisable hors contexte. Concrètement, votre site n'a jamais le vrai numéro : le PSP le capturé dans un champ hébergé ou un iframe, le stocké chez lui, et vous renvoie un token. Pour facturer à nouveau (abonnement, achat en un clic), vous envoyez le token, pas la carte.

Avantages :

• Réduction drastique du périmètre PCI-DSS (voir plus bas) : si vous ne touchez jamais le PAN, vos obligations s'allègent énormément.
• Paiements récurrents sécurisés sans stocker de données sensibles.
• En cas de fuite de votre base, aucun numéro de carte exploitable ne sort.

Règle absolue : ne stockez jamais un PAN complet, un CVV (interdit de le stocker, point), ni une bande magnétique en clair dans votre base ou vos logs. Si un développeur vous propose de garder les cartes en base pour faire des récurrences maison, refusez : utilisez les tokens du PSP.

OTP et vérification côté mobile money

Sur Wave et Orange Money, l'authentification du payeur est gérée par l'opérateur (code PIN, confirmation in-app). Votre travail de marchand n'est pas d'authentifier le payeur, mais de vérifier que le paiement a vraiment eu lieu avant de livrer. Deux règles :

• Ne jamais valider une commande sur la base d'une capture d'écran. Les captures se truquent en trente secondes. La seule preuve valable est la notification de votre PSP/agrégateur ou de l'API opérateur.
• Attendre le webhook de confirmation (statut "completed"/"success") avant de déclencher la livraison ou le service. Un statut "pending" n'est pas un paiement.

Si vous proposez du paiement par OTP côté site (rare hors carte), assurez-vous que l'OTP a une durée de vie courte (60 à 120 secondes), un nombre de tentatives limité (3 à 5) et qu'il n'est jamais logue en clair.

Signatures de webhook : la défense oubliée

C'est la faille la plus fréquente et la plus grave que nous auditons. Beaucoup de sites reçoivent les notifications de paiement (webhooks) sur une URL publique et font confiance au contenu sans vérifier la signature. Un attaquant qui devine l'URL peut alors envoyer un faux webhook "paiement réussi" et obtenir gratuitement la marchandise.

Bonnes pratiques impératives :

• Vérifiez la signature HMAC de chaque webhook avec la clé secrète fournie par le PSP. PayDunya, CinetPay et Hub2 fournissent tous un mécanisme de signature ou un token. Rejetez tout webhook dont la signature ne correspond pas.
• Re-vérifiez le statut côté API : après réception du webhook, rappelez l'API du PSP pour confirmer le montant et le statut. Ne vous fiez pas uniquement au payload reçu.
• Idempotence : un même événement peut être envoyé plusieurs fois. Stockez l'identifiant de transaction et ignorez les doublons pour ne pas créditer deux fois.
• Validez le montant et la devise reçus contre la commande attendue. Un webhook "réussi" pour 100 FCFA sur une commande de 100 000 FCFA doit être rejeté.

PCI-DSS : quand et à quel niveau cela vous concerné

PCI-DSS est la norme de sécurité des données de carte. Bonne nouvelle pour la majorité des PME sénégalaises : si vous utilisez un champ de paiement hébergé ou une redirection vers le PSP (vous ne touchez jamais le PAN), vous relevez du niveau de conformité le plus léger, le SAQ A, un questionnaire d'auto-évaluation court.

• Vous redirigez vers la page du PSP ou utilisez un iframe/Hosted Fields : SAQ A, périmètre minimal. C'est l'architecture à viser.
• Vous capturez le numéro sur votre propre formulaire (même transmis directement au PSP) : SAQ A-EP, plus contraignant.
• Vous stockez ou traitez le PAN sur vos serveurs : SAQ D, lourd, audits, scans. À éviter absolument pour une PME.

Conclusion pratique : choisissez une intégration ou le PSP capture la carte. Vous n'avez alors quasiment aucune contrainte PCI lourde, et vous reportez le risque le plus toxique sur des acteurs équipés pour le porter.

Mini cas : une boutique mode à Dakar passe de 4,2 à 0,3 pour cent de fraude

Une boutique de mode en ligne basée à Dakar faisait environ 3,8 millions FCFA de ventes mensuelles, dont 40 pour cent par carte (clientèle diaspora) et 60 pour cent en Wave/OM. Elle subissait 4,2 pour cent de transactions frauduleuses côté carte : carding nocturne et chargebacks. Coût mensuel des fraudes et frais associés : environ 190 000 FCFA, sans compter le temps passé.

Interventions, en six semaines :

• 3DS2 activé sur 100 pour cent des paiements carte (auparavant désactivé pour "fluidifier" le tunnel). Les chargebacks pour fraude ont chuté parce que la responsabilité à basculé côté émetteur.
• Rate limiting sur le formulaire de paiement (max 3 tentatives par carte, captcha après 2 échecs) : le carding nocturne est devenu inexploitable.
• Vérification de signature des webhooks ajoutée (auparavant absente) plus re-vérification API du statut et du montant.
• Règle anti-capture côté service client : aucune livraison sans statut "success" confirmé par le PSP.

Résultat après deux mois : taux de fraude tombe à 0,3 pour cent, coût mensuel de fraude sous 20 000 FCFA, et zéro faux paiement mobile money valide à tort. Le taux d'abandon au paiement n'a augmente que de 1,1 point, largement absorbé par les pertes évitées.

Une checklist anti-fraude pour PME

• 3DS2 actif sur toute transaction carte, sans exception.
• Tokenisation systématique, aucun PAN ni CVV stocké.
• Webhooks signés et re-vérifiés côté API, avec idempotence.
• Rate limiting et captcha sur le formulaire de paiement.
• Règle fermé : pas de livraison sur capture d'écran.
• Séparation des rôles : celui qui rembourse n'est pas celui qui valide.
• Journalisation des remboursements et alerte sur tout remboursement vers un numéro non lié à une commande.
• Suivi mensuel du taux de chargeback et du taux de litige mobile money.

FAQ

Le 3-D Secure ne fait-il pas fuir mes clients ?

Il ajoute une étape, donc un peu d'abandon. Mais le 3DS2 "frictionless" évite l'OTP sur les transactions jugées sûres, et le coût d'un seul chargeback dépasse souvent la marge de plusieurs commandes abandonnées. Sur la carte, le 3DS n'est pas optionnel : c'est ce qui vous protège juridiquement.

Y a-t-il des chargebacks sur Wave et Orange Money ?

Non, pas au sens carte. Le mobile money ne connaît pas le chargeback automatique. En revanche les opérateurs traitent des litiges et des remboursements, et la fraude y prend la forme d'ingénierie sociale. La défense est procédurale : vérifier chaque paiement côté opérateur, jamais sur capture.

Dois-je être certifié PCI-DSS pour vendre avec la carte au Sénégal ?

Si vous utilisez une page de paiement hébergée ou un iframe du PSP, vous relevez du SAQ A, une auto-évaluation légère : vous n'avez pas à passer un audit lourd. Évitez toute architecture ou la carte transite par vos serveurs.

Comment savoir si un paiement mobile money est réellement arrivé ?

Uniquement via la notification de votre PSP/agrégateur ou via l'API opérateur, et idéalement via un webhook signé que vous re-vérifiez. Une capture d'écran, un SMS transfère ou un message WhatsApp ne sont jamais des preuves valables.

Quel est le risque numéro un que vous voyez chez les marchands ?

Les webhooks non signés. Un site qui croît un faux webhook "paiement réussi" livré gratuitement. C'est la faille la plus facile à exploiter et la plus facile à corriger : vérifier la signature et re-interroger l'API du PSP.

Discutons de votre projet. Si vous encaissez en ligne au Sénégal et voulez auditer puis durcir votre sécurité de paiement (3DS, tokenisation, webhooks signés, règles anti-fraude), nous le faisons. Écrivez-nous sur WhatsApp +221 77 596 93 33.