Fake orders are one of the most frustrating problems a WooCommerce store owner can face. Bots placing hundreds of fraudulent orders, card-testing attacks draining gateway fees, and phantom customers clogging up your order list. We recently battled a persistent wave of fake orders on a client’s store — and won. Here’s everything we learned.
The Problem: Bots that won’t quit
Our client, a commercial equipment retailer, started seeing a pattern: orders from unknown sources, often for specific dollar amounts, placed by emails that didn’t match any real customer. The orders would either fail at the payment gateway (card-testing) or slip through with stolen card details.
The standard WooCommerce setup has almost no built-in protection against this. Payment gateways catch some bad cards, but by then you’ve already paid processing fees and your order list is a mess.
Layer 1: Block Known Bad Actors at Checkout
The first and most effective layer is stopping known fraudsters before they even place an order. This means maintaining blacklists of:
- Email addresses — specific addresses or patterns that have been used in fraud
- IP addresses — supports individual IPs and CIDR ranges (e.g.,
192.168.1.0/24) - Phone numbers — with wildcard support for area code blocking
These checks run during WooCommerce’s checkout validation — the order is rejected with a generic “security concerns” message before any payment is attempted. The customer never knows which check caught them, which makes it harder for bots to adapt.
Layer 2: Post-Payment Fraud Analysis
Some checks can’t run at checkout without causing false positives. The big one: unknown order origin.
WooCommerce tracks where orders come from using an attribution cookie. Orders placed through the normal checkout flow get tagged with a source. Bot-placed orders typically show as “unknown” because bots don’t execute the JavaScript that sets this cookie.
Critical lesson: We initially blocked orders with unknown origin at checkout. This immediately caused legitimate customers to be blocked — anyone using Safari with ITP (Intelligent Tracking Prevention), privacy-focused browser extensions, or sites with aggressive caching would lose the attribution cookie. The fix: only check origin after payment, and flag the order for review rather than blocking the customer entirely.
Post-payment analysis checks everything: origin, suspicious amounts, blacklists, proxy detection, and IP repeat rates. Suspicious orders get automatically moved to a custom “Fraud — Auto Cancelled” status and trigger an email alert to the store admin.
Layer 3: Catch Failed Orders too
Here’s something that’s easy to miss: bot card-testing orders always fail at the payment gateway. The bot submits stolen card numbers to see which ones are valid. The gateway declines most of them, so the order ends up with a “Failed” status.
The problem? Failed orders never reach the thank-you page, so your post-payment fraud detection never fires. Your fraud detection is completely blind to these orders.
The fix: hook into “Failed” and “Cancelled” order status transitions — but only for orders placed via the Store API. Why the distinction? Legitimate customers whose card gets declined will naturally retry, often multiple times from the same IP. If you analyze every failed order, those retries trigger your IP repeat detection and suddenly a real customer is flagged as fraud. By limiting failed-order analysis to Store API orders (which legitimate customers on a classic checkout never produce), you catch the bots without punishing real people for having a bad card day.
Layer 4: Harden the REST API
This was the biggest lesson of all. Modern WooCommerce uses the Store API for its Block Checkout. This is a public REST endpoint that accepts order submissions — and bots figured out they could POST directly to it, bypassing your checkout page entirely.
The solution: intercept REST API requests and block unauthenticated order creation attempts. But you need to be smart about what you allow through:
- Admin users with WooCommerce management capability — always allowed
- WooCommerce API key authentication — for third-party integrations
- OAuth/Bearer token authentication — for mobile apps and external services
- Valid Store API nonce — this is how legitimate Block Checkout works
The nonce Trap
This is critical and worth its own section. When we first implemented REST hardening, we verified nonces strictly using WordPress’s nonce verification. Then we worried about edge cases and relaxed it to a presence-only check — just verify that a nonce header exists, without actually validating it.
Within hours, bots adapted. They started sending requests with a fake nonce header containing garbage values. Our presence-only check let them right through.
Lesson learned: Always verify nonces strictly. Legitimate Block Checkout always has a valid nonce because WooCommerce’s JavaScript generates it fresh on each page load. Bots can fake headers but they can’t forge valid WordPress nonces — they’d need to execute JavaScript on your actual site to get one.
Layer 5: Rate Limiting by IP
Even with all the above, a determined attacker can rotate emails and details. What they can’t easily rotate is their IP address (or at least their IP pool is limited). Tracking orders per IP within a configurable time window adds another safety net.
If the same IP places more than X orders within Y minutes, all subsequent orders from that IP get flagged. This catches the rapid-fire card-testing pattern that bots use.
Making it manageable: The Admin Experience
All of this is useless if the store admin can’t see what’s happening. A few things that made a real difference:
- Custom order status filter — A “Fraud” tab in the orders list, right alongside Processing, Completed, and Cancelled. One click to see all flagged orders.
- Email alerts — Instant notification when a suspicious order is detected, with order details, billing info, and the specific fraud indicators that triggered it.
- Configurable toggles — Every detection rule can be turned on/off independently. REST hardening has its own toggle. This lets you dial in the right balance for your store.
What We got Wrong along the Way
Transparency matters. Here are the mistakes we made so you don’t have to:
- Blocking unknown origin at checkout — Caused false positives for Safari users and anyone with privacy extensions. Moved to post-payment only.
- Relaxing nonce verification — Bots immediately exploited the presence-only check. Never compromise on nonce validation.
- Assuming failed orders don’t matter — Card-testing bots generate hundreds of failed orders that were invisible to our fraud checks. You need to analyze failed orders — but selectively (see next point).
- Analyzing all failed orders the same way — Our initial fix ran every fraud check on every failed order. This caught bots, but it also caught legitimate customers who retried after a declined card. Multiple retries from the same IP triggered our rate limiting, and real customers started appearing in the “Top Fraud Emails” report. The fix: only run fraud analysis on failed orders that came through the Store API — the channel bots use. Failed orders from the normal checkout page are left alone.
- HTML in plain-text emails — WooCommerce’s price formatting functions return HTML with
<span>tags. In a plain-text email, that’s unreadable. Always strip HTML when building plain-text content.
The Results
After implementing all five layers, the store went from dozens of fake orders per day to zero. Legitimate customers weren’t affected — the only check that could cause false positives (unknown origin) runs post-payment and flags for review rather than blocking.
The key insight: no single check is enough. Bots adapt. What stops them is layered defense — each layer catches what the others miss. Blacklists stop known bad actors. Post-payment analysis catches new patterns. REST hardening blocks the API abuse vector. Rate limiting catches the high-volume automated attacks. Together, they form a net that’s very hard to slip through.
Want This for Your Store?
We built this as a WordPress plugin called WC Antifraud. It’s Open-Source and available on GitHub. If your WooCommerce store is dealing with fake orders, card-testing attacks, or bot abuse, it might be exactly what you need.
The plugin handles all five layers described above, with a clean settings UI, email alerts, activity logging, and a reports dashboard. It works with both the classic checkout and the new Block Checkout, and it’s compatible with WooCommerce’s HPOS (High-Performance Order Storage).
Check it out on GitHub — and if you need help setting it up or customizing it for your store, get in touch.
