It's 2 a.m. and your payment gateway dashboard lights up with 140 orders in eleven minutes — all under €15, all different card numbers, all shipping to freight-forwarder addresses in three cities you've never sold to before. By the time your morning coffee is ready, your acquiring bank has flagged your account for a chargeback review and your fulfilment team has already boxed forty of those orders. This is card testing, and it's one of the more mundane ways an unprotected PrestaShop store loses money before anyone on the team even notices.
Fraud in eCommerce isn't a single problem — it's a family of problems (stolen-card testing, account takeover, friendly fraud, promo abuse, refund fraud) that all show up looking like "just an order." Rules-based filters catch the obvious cases. What they miss is the pattern that only becomes visible when you look across hundreds of orders at once — which is exactly where machine learning earns its keep.
Why rule-based fraud checks stop working
Most PrestaShop stores start with something simple: block orders over a certain value from free email domains, flag anything with a mismatched billing/shipping country, cap orders per IP per hour. These rules work — until fraud rings adapt to them, which usually takes about a week.
The problem is structural. A static rule ("block if order > €500 and billing ≠ shipping country") can only ever encode what you already know about past fraud. It can't catch a new pattern, and it generates false positives against legitimate customers who happen to be travelling, gifting, or using a company card with a different billing address than their home. I've seen stores lose more revenue to over-aggressive static rules blocking genuine buyers than they ever saved by stopping fraud.
What "AI fraud detection" actually means
Strip away the marketing language and AI-based fraud detection for online stores usually comes down to two techniques working together:
- Supervised classification — a model trained on thousands of past orders labelled "fraud" or "legitimate," learning which combinations of signals (velocity, device fingerprint, IP reputation, time-of-day, cart contents, typing cadence on the checkout form) correlate with chargebacks.
- Unsupervised anomaly detection — no labels needed. The model learns what "normal" order behaviour looks like for your store specifically, then scores new orders by how far they deviate from that baseline. This is what catches novel fraud patterns rules can't, because it doesn't need to have seen the pattern before.
A mature setup blends both: the anomaly score raises a flag, the classifier decides how confident to be, and a human (or an automated workflow) makes the final call on borderline cases.
The signals that actually matter
Not every data point is equally useful, and I'd rather see a store use six good signals well than twenty mediocre ones badly.
| Signal category | Example data points | Why it matters |
|---|---|---|
| Velocity | Orders per card/IP/device in last 1h, 24h, 7d | Card testing and bot attacks are fast by nature |
| Device & network | Device fingerprint, browser entropy, proxy/VPN/Tor detection, IP-to-billing distance | Fraud rings reuse devices and infrastructure across "different" identities |
| Behavioural | Mouse movement, typing rhythm, time-to-checkout, copy-paste in card fields | Bots and scripted fraud behave differently from humans, even when data looks clean |
| Historical | Account age, past order/return ratio, email domain age | New accounts making high-value first orders are statistically riskier |
| Payment-specific | AVS/CVV match results, BIN country vs shipping country, card issuer risk score | Direct signal from the payment processor's own fraud stack |
None of these alone is proof of fraud — a customer using a VPN for privacy reasons isn't automatically a fraudster, and neither is someone buying a gift for delivery abroad. The model's job is to weigh dozens of weak signals into one confidence score, which is precisely the kind of pattern-matching machine learning is good at and manual review is slow at.
Building it into a PrestaShop workflow
You don't need to train your own model from scratch, and honestly, for most stores under a few thousand orders a month, doing so isn't worth the engineering cost. Three practical paths:
- Payment processor native tools. Stripe Radar, Adyen RevenueProtect, and PayPal's fraud protection all ship built-in ML scoring that reads your transaction history automatically. If you already process payments through one of these, turning on the fraud module is the cheapest first step.
- Dedicated fraud-detection modules/services integrated via API — these specialise in eCommerce-specific signals and often let you set your own risk-score thresholds for auto-approve/hold/decline.
- Custom scoring logic built on your order database for stores with distinctive risk patterns (high-value electronics, digital goods, subscription boxes) that generic tools don't model well.
Whichever you choose, resist the urge to auto-decline everything above a risk threshold. Route the middle band — say, scores between 40 and 75 out of 100 — to manual review with a short SLA (under 30 minutes if you can manage it) rather than an outright block. That middle band is where you protect revenue without alienating real customers.
A practical rollout checklist
- [ ] Turn on your payment processor's native fraud scoring and review its default thresholds against last quarter's actual chargebacks
- [ ] Set velocity limits per IP, device, and card BIN, tuned to your normal order volume (not a generic default)
- [ ] Route mid-risk orders to manual review instead of binary approve/decline
- [ ] Log every fraud decision with the signals that drove it — you'll need this both for tuning and for GDPR accountability
- [ ] Re-run a false-positive audit monthly: how many "declined" orders were actually legitimate customers?
- [ ] Keep a human override path — support staff should be able to release a wrongly held order in minutes, not days
Where this runs into EU rules
Fraud scoring touches personal data and automated decision-making, so it isn't a pure engineering problem. Under GDPR, an order decline driven entirely by an automated model, with no human involved, can trigger the Article 22 right not to be subject to a decision based solely on automated processing where it produces a legal or similarly significant effect. In practice this means: keep a human in the loop for outright declines, document the logic in plain language for your privacy notice, and don't silently profile customers beyond what's needed to stop fraud.
The EU AI Act (Regulation (EU) 2024/1689) also matters here, though its heaviest obligations fall on "high-risk" AI systems — categories like credit scoring, not typical eCommerce fraud filters. Still, the Act's general principles around transparency and human oversight are a sensible baseline to build to even where you're not formally in scope. If you're building out a broader compliance picture, our <a href="/blog/eu-ai-act-online-stores-impact/">guide to the EU AI Act's impact on online stores</a> covers where the thresholds actually bite.
Fraud prevention also sits close to account security — a fraud ring that's compromised customer accounts via credential stuffing will generate different signals than one testing stolen cards, and your defence needs to cover both. See our piece on <a href="/blog/account-takeover-protection-online-stores/">account takeover protection</a> for the account-side half of this problem, and <a href="/blog/preventing-fake-orders-with-ai/">preventing fake orders with AI</a> for a deeper look at order-specific scoring models.
What this costs versus what fraud costs
Illustrative numbers, not a benchmark: a mid-sized PrestaShop store doing €2M/year might see chargeback rates around 0.3-0.6% without active fraud tooling, each chargeback costing the order value plus a €15-25 processor fee plus the lost goods. A fraud-scoring layer costing a few hundred euros a month in processor fees or module subscriptions that cuts chargebacks by even a third usually pays for itself within the first losing month it prevents. The bigger cost, in my experience, isn't the tooling — it's the operational discipline of actually reviewing the flagged orders instead of letting the queue pile up.
Putting AI fraud detection to work
Pull your last 90 days of chargebacks and refunds flagged as fraud, and map them against the signals table above — velocity, device, payment-specific. If more than half cluster around one or two signal types, that's your cheapest starting point: enable or tune the matching detection rule before you spend on anything more sophisticated.
Frequently asked questions
Does AI fraud detection replace manual review entirely?
No, and it shouldn't try to. AI scoring is best used to triage volume — auto-approving the clearly safe majority and auto-declining the clearly fraudulent minority — while routing the ambiguous middle band to a human. Full automation without review increases both false declines and GDPR exposure.
How much order history do I need before machine learning is useful?
Supervised models need a meaningful sample of labelled fraud and legitimate orders to learn from — typically a few hundred confirmed fraud cases minimum. Below that volume, anomaly-detection approaches or a processor's pooled-data model (trained across many merchants) will outperform anything you could train yourself.
Will fraud filters block legitimate international customers?
They can, if tuned poorly. Billing/shipping mismatches and VPN usage are weak signals on their own and shouldn't trigger automatic declines. Combine them with velocity and behavioural signals, and route ambiguous cases to manual review rather than blocking outright.
Is AI fraud scoring GDPR compliant?
It can be, provided you avoid purely automated declines with no human oversight for consequential decisions, document your logic in your privacy notice, and only collect signals proportionate to the fraud-prevention purpose. Article 22 GDPR is the specific provision to check against.
What's the fastest fraud pattern to defend against?
Card testing — rapid, low-value orders across many card numbers — because it's high-volume and low-sophistication. Velocity limits per IP, device, and card BIN catch most of it without needing a trained model at all.
Do small stores really need this, or is it overkill?
Below a few dozen orders a day, a trained ML model is overkill, but your payment processor's built-in fraud scoring (Stripe Radar, Adyen, PayPal) is free or near-free and worth enabling regardless of size. Custom modelling becomes worthwhile once fraud losses are a measurable line item.
Related reading
- Preventing Fake Orders with AI
- Account Takeover Protection for Online Stores
- How Zero Trust Security Can Protect eCommerce Businesses
- Future Cybersecurity Threats Facing eCommerce
- GDPR Security Best Practices Beyond Compliance
