This service is built specifically for WordPress and WooCommerce stores. We do not currently offer this fraud prevention service for Shopify or other e-commerce platforms.
On this page: why generic fraud plugins often fall short, what a custom solution actually includes, a real project walkthrough, and answers to the questions we hear most before starting.
Why Generic Fraud Plugins Often Aren’t Enough
Search for a WooCommerce fraud prevention solution and you’ll find dozens of plugins — real, useful tools for many stores. But generic plugins work from generic rules, and a determined attacker only has to learn what those rules are once.
In one engagement, a client had already tried his payment gateway’s built-in fraud suite, velocity filters, address verification, CVV checks, and reCAPTCHA — all before contacting us. Every one of them failed, and the reasons why are instructive:
- The gateway’s fraud filters were tuned to catch bursts of activity. The attack ran at a steady, deliberate 45-second interval — comfortably beneath any burst threshold, and paced specifically to stay there.
- Velocity, address, and CVV filters were defeated by rotation — the attack used over 200 distinct IP addresses and billing addresses spanning dozens of US states, a fresh identity on nearly every attempt.
- reCAPTCHA was already installed, and was being defeated throughout.
- Changing the targeted product (something the client tried on his own) bought only a few days — the attacker’s script re-scraped the catalogue and re-targeted almost immediately.
None of these tools were poorly chosen. They were designed to catch a different kind of attacker than the one actually present — and a generic plugin, by definition, can’t adapt to that gap the way a solution built around your store’s actual attack pattern can.
What’s Included
A custom WooCommerce fraud prevention engagement typically includes:
- A fraud pattern audit — reviewing your actual order data, logs, and attack patterns to understand what’s specifically happening on your store, including comparing your payment gateway’s visibility against what’s actually hitting your server (in one case, the gateway dashboard showed roughly a fifth of the real attack volume — the rest was failing validation before ever reaching it).
- Custom plugin development — detection logic built around your store’s specific attack signals, not a generic pattern library. Depending on what the audit finds, this can include things like request header integrity checks, honeypot fields invisible to human visitors, and submission-timing analysis.
- Deployment in monitor mode first — before anything blocks real traffic, the detection logic runs silently against live data to validate accuracy. In one engagement, this caught 449 of 462 real attack attempts with zero false positives on genuine customers, confirmed before the switch to active blocking.
- Cloudflare-level configuration — WAF rules, IP-range blocking, and geographic scoping configured to stop malicious traffic at the network edge, before it ever reaches WordPress. Rules are scoped carefully to avoid affecting legitimate traffic or search visibility (in one case, a geographic restriction was applied only to the checkout submission step, confirmed to affect 0% of legitimate traffic, while browsing and content remained open worldwide).
- Defense in depth, not a single point of failure — Cloudflare and the custom plugin each catch things the other can’t. Cloudflare blocks before a request consumes server resources and keeps working even if WordPress itself is misconfigured; the plugin sees fully parsed order data Cloudflare can’t inspect. In practice, each layer has caught attack attempts the other layer missed.
- Active monitoring, not a build-and-walk-away deliverable — determined attackers adapt. In one engagement, the attacker changed tactics three separate times in the days after launch (switching browser signatures, rotating to new network infrastructure, probing an alternate checkout API), and each adaptation was detected and countered within hours.
Not included by default: transaction-level fraud scoring services (e.g., device fingerprinting and reputation-based scoring tools), CAPTCHA replacement, and 3D Secure implementation are natural next steps we often recommend alongside this work, but are separate from the core build — see “What We’d Recommend Next” below.
Signs You Need Custom Fraud Prevention (Not Just a Plugin)
You likely need something beyond an off-the-shelf plugin if:
- You’re already running fraud prevention tools and still seeing a persistent, adapting pattern of fake orders or chargebacks
- Your payment gateway’s fraud dashboard doesn’t match what you’re actually seeing in your order list — a real sign the gateway isn’t seeing the full picture
- Your fraud attempts follow a specific, recognizable pattern that generic tools don’t seem to catch, or that keeps returning after you block it once
- Chargebacks, gateway fees on declined attempts, or corrupted sales data are costing you enough that a custom solution’s cost is easily justified
- You’re seriously considering disabling a payment method or feature to stop the fraud — often a sign the actual problem hasn’t been correctly diagnosed yet
If you’re facing occasional, generic fraud attempts, a well-configured off-the-shelf plugin may be genuinely sufficient — we’re happy to have that honest conversation during a fraud pattern audit before recommending custom development.
Real Result: Automated Card Testing Attack on an Industrial Supplies Retailer
(Business anonymized per client agreement — described only by general category.)
An established B2B/B2C industrial safety products retailer, running an established WooCommerce store with US-only shipping, came to us after roughly seven weeks of what he believed was manual fraud. It wasn’t — and diagnosing that correctly was the turning point that made a real fix possible.
The real problem: automated card testing, not manual fraud
The store was being used as a testing instrument for stolen credit card data — a scripted browser automation loaded the real checkout page, harvested a valid session, and submitted transactions at a steady, deliberate pace to check which stolen card numbers were still active. The merchant wasn’t the target; the merchant’s checkout was just the tool.
The scale, once we could actually see it, was significant: roughly 115 attack attempts per day, with up to 84 fraudulent orders created in a single day. 82% of all orders in the system were fraudulent. And the client’s payment gateway dashboard — the tool he’d been using to judge the scale of the problem — was only showing him about a fifth of it, since most attempts failed WooCommerce’s own validation before ever reaching the gateway.
What didn’t work, and why
Before engaging us, the client had exhausted his payment gateway’s built-in fraud suite, velocity and address filters, CVV checks, and reCAPTCHA — all defeated for structural reasons (detailed above). He’d also tried changing the targeted product himself; the attacker’s script re-scraped the catalogue and re-targeted within days. Disabling the payment gateway entirely stopped the fraud, but stopped legitimate sales too, and wasn’t commercially viable.
What we built
A custom must-use WordPress plugin hooking into WooCommerce’s checkout validation, combined with Cloudflare Pro as a network-level enforcement layer (the site had no CDN or WAF in place previously). The two layers work together as defense in depth: Cloudflare blocks the majority of attack traffic at the edge, before it ever reaches the server; the plugin catches what gets through, using signals Cloudflare can’t see, like fully parsed order and billing data.
The detection logic itself was built around real, observed attack behavior — including a header-integrity check based on a specific gap in how the attacker’s automation identified itself as a real browser, carefully scoped to avoid flagging genuine users of other browsers. Before any of it blocked a single real transaction, it ran in monitor mode against live traffic to confirm accuracy: 449 of 462 captured attack attempts detected, zero false positives on genuine customers.
Results
| Measure | Before | After |
|---|---|---|
| Attack attempts per day | ~115 | 12 (background noise — scanners, not card testing) |
| Fraudulent orders created | up to 84/day | 0 |
| Share of orders that were fraudulent | 82% | 0% |
| Legitimate customers blocked | — | 0 |
Results were visible the same day the solution went live — 47 attack requests were blocked at the edge within the first hour. Attack volume fell from roughly 97 to 44 to 12 events per day over the following days as the remaining activity dropped to ordinary internet background noise.
A secondary result worth including: during the engagement, the client was preparing to disable card payments during business hours, believing a batch of transactions were fraudulent. Analysis of the actual attack data showed they were genuine customers whose cards had simply declined — including real revenue already captured and pending settlement, and one lost sale worth several hundred dollars that was identified and flagged for recovery. The shutdown, which would have blocked legitimate customers, was avoided.
The honest part: this required ongoing adaptation, not a one-time fix
The attacker didn’t simply give up — he adapted three times in the days after launch: switching browser signatures to evade the header check, rotating to new network infrastructure as IP ranges were blocked, and probing an alternate checkout API route. Each adaptation was caught in the logs and countered within hours.
This is the honest, useful framing worth stating plainly: signature-based fraud detection has a finite lifespan. It costs an attacker very little to change one detail and evade a specific fingerprint. The real goal isn’t a single fix that ends fraud permanently — it’s building enough layered friction, and enough active monitoring, that continuing to attack a specific store stops being worth the attacker’s time. That’s what happened here.
What We’d Recommend Next
For stores facing ongoing or evolving fraud risk, a few natural extensions beyond the core build:
- Transaction-level fraud scoring (e.g., tools like MaxMind minFraud) — scores based on proxy reputation, email reputation, and device fingerprinting rather than a specific signature an attacker can simply edit around. This is the more durable long-term answer once fingerprint-based detection starts to age.
- Cloudflare Turnstile as a CAPTCHA replacement, where an existing reCAPTCHA implementation is being actively defeated.
- 3D Secure on card transactions — effectively ends card testing outright by requiring issuer-level authentication, at some cost to checkout conversion.
Related Services
- Website Maintenance — ongoing monitoring and care plans for WooCommerce stores
- Custom Web Application Development — for custom functionality beyond fraud prevention specifically
- WordPress Website Design — if fraud issues are surfacing gaps in your broader WordPress setup
- Website Optimization — for sites with broader performance or conversion issues alongside fraud concerns
