Securiser les paiements en ligne au Senegal : fraude, 3-D Secure et tokenisation en 2026

La premiere fois qu un marchand senegalais decouvre la fraude, c est rarement par une grosse perte spectaculaire. C est par une serie de petites commandes payees par carte etrangere, livrees, puis rejetees quelques semaines plus tard par la banque emettrice. Le marchand a expedie la marchandise, encaisse en apparence, puis recoit un debit de son agregateur qui lui reprend l argent. C est le scenario classique du chargeback, et il fait mal parce qu il arrive a retardement, sur une vente qu on croyait acquise.

Au Senegal, la realite de la fraude est double. D un cote le mobile money (Wave, Orange Money, Free Money) ou il n existe pas de chargeback, mais ou la fraude prend la forme d ingenierie 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), ou la fraude classique aux numeros voles et le chargeback existent bel et bien. Securiser ses paiements, ce n est donc pas appliquer une recette unique : c est comprendre quel canal porte quel risque et y mettre la bonne defense.

Cet article decrit les types de fraude que nous voyons concretement chez nos clients e-commerce au Senegal, puis les mecanismes techniques qui les contrent : 3-D Secure, tokenisation, OTP mobile money, verification des signatures de webhook, et le perimetre PCI-DSS quand on touche a la carte. L objectif n est pas la paranoia, mais un niveau de protection proportionne au volume et au panier moyen.

Les types de fraude reels au Senegal

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

• Fraude a la carte volee (carding) : un attaquant teste des numeros de carte voles sur votre site, souvent par petits montants pour valider que la carte fonctionne. Vous voyez une rafale de tentatives, beaucoup d echecs, quelques succes. Les cartes etant etrangeres, le chargeback suit.
• Chargeback abusif (friendly fraud) : le client a bien recu le produit mais conteste le debit aupres de sa banque. Sans 3-D Secure, c est le marchand qui perd. Avec 3-D Secure, la responsabilite bascule souvent vers l emetteur.
• Ingenierie sociale mobile money : un faux acheteur envoie une fausse capture d ecran de paiement Wave ou Orange Money, ou pretend avoir paye en trop et demande un remboursement de la difference. La capture est truquee, le paiement initial n existe pas.
• Arnaque au remboursement : le fraudeur paie reellement, recoit le bien, puis ouvre un litige aupres de l operateur en pretendant ne pas avoir recu, ou paie depuis un compte lui-meme vole.
• Account takeover : prise de controle d un compte client (mot de passe reutilise, OTP intercepte) pour passer des commandes ou changer l adresse de livraison.
• Fraude interne : un employe cree de faux remboursements vers son propre numero. C est sous-estime et pourtant frequent dans les petites structures sans separation des roles.

Le point cle : sur mobile money, la defense est surtout procedurale (ne jamais se fier a une capture, toujours verifier la transaction cote operateur ou via le webhook signe). Sur carte, la defense est surtout technique (3-D Secure, scoring, tokenisation).

3-D Secure : faire basculer la responsabilite

Le 3-D Secure (Verified by Visa, Mastercard Identity Check) ajoute une etape d authentification forte cote porteur : OTP envoye par la banque emettrice, ou validation dans l application bancaire. Pour le marchand, l interet n est pas seulement de bloquer des fraudeurs, c est le liability shift : sur une transaction authentifiee en 3DS, en cas de contestation pour fraude, c est generalement la banque emettrice qui supporte la perte, pas le marchand.

En pratique au Senegal, la quasi-totalite des PSP qui acceptent la carte (PayDunya, CinetPay, Hub2, Paystack, Stripe pour ceux qui ont une entite hors zone) proposent ou imposent le 3DS2. Recommandations concretes :

• Activez le 3DS sur 100 pour cent des transactions carte, meme si le taux d abandon monte legerement. Le cout d un chargeback (montant + frais de 5 000 a 15 000 FCFA selon le PSP + impact sur votre taux de litige) depasse largement la marge perdue sur quelques abandons.
• Surveillez votre taux de chargeback. Au-dela de 1 pour cent des transactions, les reseaux 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 evite l OTP quand la transaction est jugee sure (frictionless flow), ce qui ameliore la conversion.

Tokenisation : ne jamais stocker un numero de carte

La tokenisation remplace le numero de carte (PAN) par un jeton inutilisable hors contexte. Concretement, votre site n a jamais le vrai numero : le PSP le capture dans un champ heberge ou un iframe, le stocke chez lui, et vous renvoie un token. Pour facturer a nouveau (abonnement, achat en un clic), vous envoyez le token, pas la carte.

Avantages :

• Reduction drastique du perimetre PCI-DSS (voir plus bas) : si vous ne touchez jamais le PAN, vos obligations s allegent enormement.
• Paiements recurrents securises sans stocker de donnees sensibles.
• En cas de fuite de votre base, aucun numero de carte exploitable ne sort.

Regle absolue : ne stockez jamais un PAN complet, un CVV (interdit de le stocker, point), ni une bande magnetique en clair dans votre base ou vos logs. Si un developpeur vous propose de garder les cartes en base pour faire des recurrences maison, refusez : utilisez les tokens du PSP.

OTP et verification cote mobile money

Sur Wave et Orange Money, l authentification du payeur est geree par l operateur (code PIN, confirmation in-app). Votre travail de marchand n est pas d authentifier le payeur, mais de verifier que le paiement a vraiment eu lieu avant de livrer. Deux regles :

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

Si vous proposez du paiement par OTP cote site (rare hors carte), assurez-vous que l OTP a une duree de vie courte (60 a 120 secondes), un nombre de tentatives limite (3 a 5) et qu il n est jamais logue en clair.

Signatures de webhook : la defense oubliee

C est la faille la plus frequente et la plus grave que nous auditons. Beaucoup de sites recoivent les notifications de paiement (webhooks) sur une URL publique et font confiance au contenu sans verifier la signature. Un attaquant qui devine l URL peut alors envoyer un faux webhook "paiement reussi" et obtenir gratuitement la marchandise.

Bonnes pratiques imperatives :

• Verifiez la signature HMAC de chaque webhook avec la cle secrete fournie par le PSP. PayDunya, CinetPay et Hub2 fournissent tous un mecanisme de signature ou un token. Rejetez tout webhook dont la signature ne correspond pas.
• Re-verifiez le statut cote API : apres reception du webhook, rappelez l API du PSP pour confirmer le montant et le statut. Ne vous fiez pas uniquement au payload recu.
• Idempotence : un meme evenement peut etre envoye plusieurs fois. Stockez l identifiant de transaction et ignorez les doublons pour ne pas crediter deux fois.
• Validez le montant et la devise recus contre la commande attendue. Un webhook "reussi" pour 100 FCFA sur une commande de 100 000 FCFA doit etre rejete.

PCI-DSS : quand et a quel niveau cela vous concerne

PCI-DSS est la norme de securite des donnees de carte. Bonne nouvelle pour la majorite des PME senegalaises : si vous utilisez un champ de paiement heberge ou une redirection vers le PSP (vous ne touchez jamais le PAN), vous relevez du niveau de conformite le plus leger, le SAQ A, un questionnaire d auto-evaluation court.

• Vous redirigez vers la page du PSP ou utilisez un iframe/Hosted Fields : SAQ A, perimetre minimal. C est l architecture a viser.
• Vous capturez le numero sur votre propre formulaire (meme transmis directement au PSP) : SAQ A-EP, plus contraignant.
• Vous stockez ou traitez le PAN sur vos serveurs : SAQ D, lourd, audits, scans. A eviter absolument pour une PME.

Conclusion pratique : choisissez une integration 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 equipes pour le porter.

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

Une boutique de mode en ligne basee a Dakar faisait environ 3,8 millions FCFA de ventes mensuelles, dont 40 pour cent par carte (clientele diaspora) et 60 pour cent en Wave/OM. Elle subissait 4,2 pour cent de transactions frauduleuses cote carte : carding nocturne et chargebacks. Cout mensuel des fraudes et frais associes : environ 190 000 FCFA, sans compter le temps passe.

Interventions, en six semaines :

• 3DS2 active sur 100 pour cent des paiements carte (auparavant desactive pour "fluidifier" le tunnel). Les chargebacks pour fraude ont chute parce que la responsabilite a bascule cote emetteur.
• Rate limiting sur le formulaire de paiement (max 3 tentatives par carte, captcha apres 2 echecs) : le carding nocturne est devenu inexploitable.
• Verification de signature des webhooks ajoutee (auparavant absente) plus re-verification API du statut et du montant.
• Regle anti-capture cote service client : aucune livraison sans statut "success" confirme par le PSP.

Resultat apres deux mois : taux de fraude tombe a 0,3 pour cent, cout mensuel de fraude sous 20 000 FCFA, et zero faux paiement mobile money valide a tort. Le taux d abandon au paiement n a augmente que de 1,1 point, largement absorbe par les pertes evitees.

Une checklist anti-fraude pour PME

• 3DS2 actif sur toute transaction carte, sans exception.
• Tokenisation systematique, aucun PAN ni CVV stocke.
• Webhooks signes et re-verifies cote API, avec idempotence.
• Rate limiting et captcha sur le formulaire de paiement.
• Regle ferme : pas de livraison sur capture d ecran.
• Separation des roles : celui qui rembourse n est pas celui qui valide.
• Journalisation des remboursements et alerte sur tout remboursement vers un numero non lie a 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 etape, donc un peu d abandon. Mais le 3DS2 "frictionless" evite l OTP sur les transactions jugees sures, et le cout d un seul chargeback depasse souvent la marge de plusieurs commandes abandonnees. Sur la carte, le 3DS n est pas optionnel : c est ce qui vous protege juridiquement.

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

Non, pas au sens carte. Le mobile money ne connait pas le chargeback automatique. En revanche les operateurs traitent des litiges et des remboursements, et la fraude y prend la forme d ingenierie sociale. La defense est procedurale : verifier chaque paiement cote operateur, jamais sur capture.

Dois-je etre certifie PCI-DSS pour vendre avec la carte au Senegal ?

Si vous utilisez une page de paiement hebergee ou un iframe du PSP, vous relevez du SAQ A, une auto-evaluation legere : vous n avez pas a passer un audit lourd. Evitez toute architecture ou la carte transite par vos serveurs.

Comment savoir si un paiement mobile money est reellement arrive ?

Uniquement via la notification de votre PSP/agregateur ou via l API operateur, et idealement via un webhook signe que vous re-verifiez. Une capture d ecran, un SMS transfere ou un message WhatsApp ne sont jamais des preuves valables.

Quel est le risque numero un que vous voyez chez les marchands ?

Les webhooks non signes. Un site qui croit un faux webhook "paiement reussi" livre gratuitement. C est la faille la plus facile a exploiter et la plus facile a corriger : verifier la signature et re-interroger l API du PSP.

Discutons de votre projet. Si vous encaissez en ligne au Senegal et voulez auditer puis durcir votre securite de paiement (3DS, tokenisation, webhooks signes, regles anti-fraude), nous le faisons. Ecrivez-nous sur WhatsApp +221 77 596 93 33.