E-commerce
Preventing card fraud without blocking real customers
Card fraud stops at three levels: risk-based challenge, transaction rules, chargeback monitoring. Plus the security headers we measured on eight shops.
Key points
- The 3-D Secure challenge is decided on risk, not applied to every transaction.
- Velocity rules stop repeated attempts without touching normal customers.
- The checkout should send a Content-Security-Policy: 3 of 8 shops do not.
- Card data must never pass through the shop server.
Card fraud defence runs on three levels: challenge on risk, transaction rules, chargeback monitoring. None of the three is decided by eye.
The three levels
| Level | What it reads | Cost for the customer |
|---|---|---|
| 3-D Secure challenge | Risk of the individual transaction, decided by the issuing bank | One extra step, only when risk is high |
| Transaction rules | Amount, billing and shipping country, repeated attempts on one card | None, when the rule fires only on edge cases |
| Review queue | Ambiguous orders, before dispatch | A disclosed delay, not a surprise |
| Chargeback monitoring | Ratio of chargebacks to transactions, read monthly | None directly, but thresholds differ per card network |
The level that costs the most in lost sales is the first, when applied to everyone: a challenge on every payment turns away anyone in a hurry. The level that costs the most money is the last, because the chargeback arrives with the goods already shipped.
The rule that avoids false positives
- Block the pattern, not the person: one IP address with three different cards in ten minutes is a signal, a customer with two cards is normal.
- Ask before cancelling: an order stopped without explanation loses a customer and earns a bad review, while a verification email costs a few minutes.
- Say it in the checkout: if shipping may need a check, write that before payment, not after.
The code: read the security headers
# le due intestazioni che rendono difficile iniettare script nel checkout
for d in esempio1.it esempio2.it; do
printf "%s csp=" "$d"
curl -sI "https://$d/" | grep -ci "content-security-policy"
done
# la pagina di pagamento carica script da domini terzi?
curl -s https://www.esempio.it/checkout \
| grep -o 'src="https://[^/"]*' | sort -uA second command returning ten different domains inside the checkout tells you where an injected script could end up. CSP does not remove the risk, but it stops scripts from unlisted domains from running: it is the most direct defence against skimming code that copies form data.
The limitation to name
The headers measured belong to the front page, not to the payment page: a shop can send them on the home page and not on the checkout, so read the data again on the URL that takes the money. The most important defence is not in your code either: if the card number passes through your server, you leave the simplified scope and your obligations change. The form belongs to the payment provider, in hosted fields or a redirect.
Where to continue
Two full checkouts to study: checkout-01 and checkout-02, both in the commerCN library. For the buying path read guest checkout, cart abandonment and the guide building an ecommerce site.
Frequently asked questions
Does 3-D Secure cost sales?
A challenge on every payment does. Applied only to risky transactions the cost is low: the issuing bank decides when to ask, and on most routine payments it never asks.
How do I recognise a fraudulent order?
Read the pattern, not one field: billing country different from shipping, an email address created days ago, several failed attempts on one card, large quantities of easily resold items. A single signal is never enough.
Who pays for a chargeback?
The shop, once the chargeback is accepted: you lose the amount, the goods already shipped and the fee. That is why monthly monitoring matters more than real-time screening.
Can card data pass through my server?
No, if you want to stay in the simplest scope: use fields hosted by the payment provider inside an iframe or a redirect. Once the card number touches your server, the security and audit obligations change substantially.
Does a small shop need a fraud service?
Not straight away. With a few orders a day, 3-D Secure on risky transactions, the provider's velocity rules and a manual review of ambiguous orders are enough. A dedicated service earns its place when volume turns that review into a full-time job.