A footwear store's finance team noticed something odd in a Monday morning report: 214 orders placed overnight, each for a single low-value item, each authorized for exactly one euro. No shipping had happened yet – these were card testing attempts, where stolen card numbers get validated in bulk against a real checkout before being sold or used for larger fraud elsewhere. None of the humans on the team were awake to catch it in real time. That's precisely the kind of pattern automated, AI-assisted fraud detection is built to catch.
The Overnight Flood of $1 Orders
Fake and fraudulent orders aren't a single problem – they're a cluster of related but distinct issues, and treating them as one thing leads to defenses that miss most of them. Card testing, friendly fraud, and fake account sign-ups each need slightly different signals to catch reliably.
What Fake and Fraudulent Orders Actually Cost
Card Testing Attacks
Card testing uses a store's checkout as a validation tool: attackers run a script through hundreds or thousands of stolen card numbers, placing small orders (or even $0 authorizations where the gateway allows it) to find which cards are still active. The store rarely sees the fraud directly – it sees payment processing fees, an inflated failed-transaction rate, and sometimes a call from its payment processor asking questions about suspicious volume.
Friendly Fraud and Chargebacks
Friendly fraud happens when a legitimate customer disputes a charge for an order they actually received, either through genuine confusion or intentional abuse of the chargeback process. It's harder to catch with automated fraud scoring because the transaction itself looked entirely normal at checkout time – the fraud signal only appears weeks later, as a chargeback.
Fake Account Sign-Ups Skewing Analytics
Bots creating fake accounts to claim first-order discounts, hoard limited stock, or pad affiliate referral numbers don't always result in a fraudulent charge, but they distort marketing analytics and can exhaust promotional budgets meant for real customers.
How AI-Driven Fraud Detection Works
Machine Learning Anomaly Detection
Rather than relying on fixed rules ("block if order value exceeds X"), machine learning models trained on historical order data learn what normal behavior looks like for a specific store and flag deviations – unusual combinations of shipping address, device, order value, and browsing pattern that a static rule would miss or over-flag. The tradeoff is that these models need enough historical data to be useful, which is a real limitation for very new or very small stores.
Velocity Checks and Behavioral Signals
Velocity checks count how many orders, login attempts, or card entries come from the same IP, device, or customer profile within a short window. A dozen orders from the same device fingerprint in ten minutes, each with a different card number, is a near-certain card testing signature regardless of order value.
AVS, CVV, and 3-D Secure 2
Address Verification System (AVS) and CVV checks confirm the billing address and card details match what the issuing bank has on file – basic but still effective filters. 3-D Secure 2, mandated under PSD2's Strong Customer Authentication rules for many EU transactions, adds a bank-side verification step (biometric, one-time code) that shifts liability away from the merchant and blocks a large share of automated card testing outright, since bots typically can't complete the authentication step.
The Legal Line: GDPR Article 22 and the AI Act
Automated fraud scoring runs into real legal boundaries once it starts making decisions with legal or similarly significant effects on a person – like automatically rejecting an order or banning an account with no human review. GDPR Article 22 gives individuals the right not to be subject to a decision based solely on automated processing in those cases, meaning stores generally need a human-in-the-loop review path for anything beyond low-stakes automated flags. The AI Act (Regulation (EU) 2024/1689) adds further obligations around transparency and risk management for AI systems used in ways that could significantly affect people, which increasingly includes fraud-scoring systems used at scale. Practically, this means: automate the flagging, keep a human in the escalation path for anything that denies service or bans an account outright.
Traditional Rules vs AI-Driven Detection
| Approach | Strength | Weakness | Best Fit |
|---|---|---|---|
| Static rules (order value, country blocklist) | Simple, transparent, fast to set up | Easy to evade once patterns are known | Small stores, early-stage fraud prevention |
| Velocity checks | Catches bulk/automated abuse well | Can flag legitimate bursts (sales events) | Card testing and bot sign-ups |
| ML anomaly detection | Adapts to evolving fraud patterns | Needs data volume, can be a black box | Established stores with order history |
| 3-D Secure 2 | Shifts liability, blocks bot-driven testing | Adds a checkout step, can affect conversion | EU card transactions under PSD2 SCA rules |
Building a Practical Fraud Prevention Stack for PrestaShop
Most PrestaShop stores don't need a bespoke ML system to get meaningful protection. A practical layering, roughly in order of implementation effort:
- Enable AVS and CVV checks at the payment gateway level
- Turn on 3-D Secure 2 for EU card transactions where your gateway supports it
- Add velocity limits on orders per IP/device within short windows
- Layer in a third-party fraud-scoring module or service once order volume justifies it
- Define a manual review queue for orders flagged above a risk threshold, with a real person making the final call
For the account-security half of this problem – since many fake orders start with a compromised customer account rather than a stolen card – see /blog/account-takeover-protection-online-stores/, and for the wider threat picture, /blog/future-cybersecurity-threats-ecommerce/.
A Fake Order Prevention Checklist
- [ ] Enable AVS and CVV verification at the gateway
- [ ] Turn on 3-D Secure 2 / Strong Customer Authentication for EU transactions
- [ ] Set velocity limits on orders and failed payment attempts per IP/device
- [ ] Add a manual review step for high-risk flagged orders, not automatic rejection
- [ ] Monitor for card testing patterns (many small orders, rapid succession, varied card numbers)
- [ ] Document the human-review process to stay within GDPR Article 22 boundaries
- [ ] Reassess fraud rules quarterly as attack patterns shift
The footwear store's finance team blocked the offending IP range and asked their payment gateway to enable stricter velocity limits going forward – a fix that took an afternoon once they knew what to look for. That's the realistic next step for most stores: check whether your gateway's AVS, CVV, and 3-D Secure 2 settings are actually turned on, since a surprising number of stores have them available but disabled by default.
Frequently asked questions
Related reading
- AI Fraud Detection for Online Stores
- Account Takeover Protection for Online Stores
- How the EU AI Act Will Affect Online Stores
- Future Cybersecurity Threats Facing eCommerce
- GDPR Security Best Practices Beyond Compliance
