Securing Online Payments in Senegal: Fraud, 3-D Secure and Tokenization in 2026

The first time a Senegalese merchant discovers fraud, it is rarely through one spectacular loss. It is usually through a series of small orders paid with foreign cards, shipped, then rejected a few weeks later by the issuing bank. The merchant shipped the goods, seemingly collected the money, then receives a debit from their aggregator that claws the money back. This is the classic chargeback scenario, and it hurts precisely because it lands late, on a sale you thought was secured.

In Senegal, the fraud reality is twofold. On one side, mobile money (Wave, Orange Money, Free Money), where there is no chargeback, but where fraud takes the form of social engineering, fake receipts and refund scams. On the other, card payments (Visa, Mastercard via PayDunya, CinetPay, Hub2 or an international PSP), where classic stolen-number fraud and chargebacks do exist. Securing your payments is therefore not a single recipe: it is understanding which channel carries which risk and applying the right defense.

This article describes the fraud types we actually see at our Senegalese e-commerce clients, then the technical mechanisms that counter them: 3-D Secure, tokenization, mobile money OTP, webhook signature verification, and the PCI-DSS scope when cards are involved. The goal is not paranoia, but a level of protection proportionate to your volume and average basket.

The real fraud types in Senegal

Before tools, name the enemy. Here is what we see most often.

• Stolen-card fraud (carding): an attacker tests stolen card numbers on your site, often with small amounts to validate that the card works. You see a burst of attempts, many failures, a few successes. As the cards are foreign, chargebacks follow.
• Abusive chargeback (friendly fraud): the customer did receive the product but disputes the charge with their bank. Without 3-D Secure, the merchant loses. With 3-D Secure, liability often shifts to the issuer.
• Mobile money social engineering: a fake buyer sends a forged Wave or Orange Money payment screenshot, or claims to have overpaid and asks for a refund of the difference. The screenshot is fake, the initial payment never happened.
• Refund scam: the fraudster actually pays, receives the goods, then opens a dispute with the operator claiming non-receipt, or pays from a stolen account.
• Account takeover: taking over a customer account (reused password, intercepted OTP) to place orders or change the delivery address.
• Internal fraud: an employee creates fake refunds to their own number. It is underestimated yet common in small structures without role separation.

Key point: on mobile money, defense is mostly procedural (never trust a screenshot, always verify the transaction on the operator side or via a signed webhook). On cards, defense is mostly technical (3-D Secure, scoring, tokenization).

3-D Secure: shifting liability

3-D Secure (Verified by Visa, Mastercard Identity Check) adds strong authentication on the cardholder side: an OTP sent by the issuing bank, or validation in the banking app. For the merchant, the value is not only blocking fraudsters, it is the liability shift: on a 3DS-authenticated transaction, in case of a fraud dispute, the issuing bank generally bears the loss, not the merchant.

In practice in Senegal, nearly every PSP that accepts cards (PayDunya, CinetPay, Hub2, Paystack, Stripe for those with an entity outside the zone) offers or enforces 3DS2. Concrete recommendations:

• Enable 3DS on 100 percent of card transactions, even if the abandonment rate rises slightly. The cost of a chargeback (amount + fees of 5,000 to 15,000 FCFA depending on the PSP + impact on your dispute rate) far exceeds the margin lost on a few abandonments.
• Monitor your chargeback rate. Above 1 percent of transactions, the networks may place you in a monitoring program, which threatens your merchant contract.
• Use 3DS2 (not the old 3DS1): it performs risk scoring and skips the OTP when the transaction is deemed safe (frictionless flow), improving conversion.

Tokenization: never store a card number

Tokenization replaces the card number (PAN) with a token that is useless out of context. Concretely, your site never has the real number: the PSP captures it in a hosted field or iframe, stores it on their side, and returns a token. To charge again (subscription, one-click purchase), you send the token, not the card.

Benefits:

• Drastically reduced PCI-DSS scope (see below): if you never touch the PAN, your obligations shrink enormously.
• Secure recurring payments without storing sensitive data.
• If your database leaks, no usable card number gets out.

Absolute rule: never store a full PAN, a CVV (storing it is forbidden, period), or a magnetic stripe in clear text in your database or logs. If a developer offers to keep cards in the database to build homemade recurring billing, refuse: use the PSP's tokens.

OTP and verification on mobile money

On Wave and Orange Money, payer authentication is handled by the operator (PIN code, in-app confirmation). Your job as a merchant is not to authenticate the payer, but to verify that the payment actually happened before delivering. Two rules:

• Never validate an order based on a screenshot. Screenshots are forged in thirty seconds. The only valid proof is the notification from your PSP/aggregator or the operator API.
• Wait for the confirmation webhook (status "completed"/"success") before triggering delivery or service. A "pending" status is not a payment.

If you offer site-side OTP payment (rare outside cards), make sure the OTP has a short lifetime (60 to 120 seconds), a limited number of attempts (3 to 5), and is never logged in clear text.

Webhook signatures: the forgotten defense

This is the most frequent and most serious flaw we audit. Many sites receive payment notifications (webhooks) on a public URL and trust the content without verifying the signature. An attacker who guesses the URL can then send a fake "payment successful" webhook and obtain goods for free.

Mandatory best practices:

• Verify the HMAC signature of every webhook with the secret key provided by the PSP. PayDunya, CinetPay and Hub2 all provide a signature or token mechanism. Reject any webhook whose signature does not match.
• Re-verify the status via the API: after receiving the webhook, call the PSP's API to confirm amount and status. Do not rely solely on the received payload.
• Idempotency: the same event may be sent several times. Store the transaction ID and ignore duplicates so you do not credit twice.
• Validate the received amount and currency against the expected order. A "successful" webhook for 100 FCFA on a 100,000 FCFA order must be rejected.

PCI-DSS: when and at what level it concerns you

PCI-DSS is the card data security standard. Good news for most Senegalese SMEs: if you use a hosted payment field or a redirect to the PSP (you never touch the PAN), you fall under the lightest compliance level, SAQ A, a short self-assessment questionnaire.

• You redirect to the PSP's page or use an iframe/Hosted Fields: SAQ A, minimal scope. This is the architecture to target.
• You capture the number on your own form (even if transmitted directly to the PSP): SAQ A-EP, more demanding.
• You store or process the PAN on your servers: SAQ D, heavy, audits, scans. To be avoided at all costs for an SME.

Practical conclusion: choose an integration where the PSP captures the card. You then have almost no heavy PCI burden, and you push the most toxic risk onto players equipped to carry it.

Mini case: a Dakar fashion shop goes from 4.2 to 0.3 percent fraud

An online fashion shop based in Dakar did about 3.8 million FCFA in monthly sales, 40 percent by card (diaspora clientele) and 60 percent on Wave/OM. It suffered 4.2 percent fraudulent transactions on the card side: nighttime carding and chargebacks. Monthly cost of fraud and associated fees: about 190,000 FCFA, not counting the time spent.

Interventions, over six weeks:

• 3DS2 enabled on 100 percent of card payments (previously disabled to "smooth" the funnel). Fraud chargebacks dropped because liability shifted to the issuer.
• Rate limiting on the payment form (max 3 attempts per card, captcha after 2 failures): nighttime carding became unworkable.
• Webhook signature verification added (previously absent) plus API re-verification of status and amount.
• Anti-screenshot rule on the support side: no delivery without a "success" status confirmed by the PSP.

Result after two months: fraud rate down to 0.3 percent, monthly fraud cost under 20,000 FCFA, and zero wrongly validated fake mobile money payments. Payment abandonment rose by only 1.1 points, largely absorbed by the avoided losses.

An anti-fraud checklist for SMEs

• 3DS2 active on every card transaction, no exceptions.
• Systematic tokenization, no PAN or CVV stored.
• Signed webhooks re-verified via the API, with idempotency.
• Rate limiting and captcha on the payment form.
• Firm rule: no delivery on a screenshot.
• Role separation: the person who refunds is not the one who validates.
• Logging of refunds and alerting on any refund to a number not linked to an order.
• Monthly tracking of chargeback rate and mobile money dispute rate.

FAQ

Doesn't 3-D Secure scare my customers away?

It adds a step, so a bit of abandonment. But 3DS2 "frictionless" skips the OTP on transactions deemed safe, and the cost of a single chargeback often exceeds the margin of several abandoned orders. On cards, 3DS is not optional: it is what protects you legally.

Are there chargebacks on Wave and Orange Money?

No, not in the card sense. Mobile money has no automatic chargeback. Operators do handle disputes and refunds, and fraud there takes the form of social engineering. Defense is procedural: verify every payment on the operator side, never on a screenshot.

Do I need PCI-DSS certification to sell with cards in Senegal?

If you use a hosted payment page or a PSP iframe, you fall under SAQ A, a light self-assessment: you do not need a heavy audit. Avoid any architecture where the card transits through your servers.

How do I know a mobile money payment actually arrived?

Only via the notification from your PSP/aggregator or via the operator API, and ideally via a signed webhook you re-verify. A screenshot, a forwarded SMS or a WhatsApp message are never valid proof.

What is the number one risk you see at merchants?

Unsigned webhooks. A site that trusts a fake "payment successful" webhook delivers for free. It is the easiest flaw to exploit and the easiest to fix: verify the signature and re-query the PSP's API.

Let's talk about your project. If you collect payments online in Senegal and want to audit then harden your payment security (3DS, tokenization, signed webhooks, anti-fraud rules), we do it. Write to us on WhatsApp +221 77 596 93 33.