If you run a WooCommerce store, you’ve probably seen it: orders that don’t make sense. A customer buys a single item, pays with a card, then immediately disappears. No follow-up email. No shipping address. Sometimes the card details are obviously fake (test numbers, invalid expiry dates).
These are bot-generated orders. And they’re more common than you think.
What’s happening
Bots are scanning the internet for WooCommerce stores and testing them for vulnerabilities. One common attack is card testing: submitting fake card numbers to see which ones get accepted. If a card is accepted, the attacker knows it’s valid and can use it for fraud elsewhere.
Your checkout form is a target. Bots are hitting it constantly, trying different card numbers, different email addresses, different shipping addresses. Most of them fail (your payment gateway rejects the card). But some get through.
Each fake order that gets created is:
- A database entry you have to clean up
- A potential security signal that something’s wrong
- A source of noise in your order data
- A possible indicator that your site has a vulnerability
More importantly, it’s a sign that your site isn’t properly protected against automated attacks.
Why this matters
At first glance, fake orders seem like a minor annoyance. You see a weird order, you delete it, you move on. But there are bigger problems:
Security signal. If your site is getting hammered with fake orders, it means bots can reach your checkout form. That’s a vulnerability in itself. It suggests your site doesn’t have proper rate limiting or bot detection.
Data pollution. Your order database gets cluttered with fake entries. Your sales reports are inaccurate. Your analytics are skewed. You can’t trust your own data.
Payment gateway costs. Every transaction attempt (even failed ones) might incur a fee. If you’re getting hundreds of fake orders a day, those fees add up.
Hosting load. Processing fake orders consumes server resources. Database writes, payment gateway API calls, email generation. If you’re getting thousands of fake orders, your server is working hard for nothing.
How to spot it
Fake orders have patterns. Look for:
- Orders with obviously fake card numbers (test cards like
4111 1111 1111 1111, or numbers that don’t pass the Luhn check) - Orders with invalid expiry dates (01/20, 12/99, etc.)
- Orders with obviously fake email addresses (
test@test.com,admin@admin.com, random strings) - Orders with incomplete or nonsensical shipping addresses
- Orders that come in rapid bursts from different IP addresses
- Orders that fail payment but still create a database entry
- Orders from known bot IP ranges or VPN services
If you’re seeing these patterns, you’ve got a bot problem.
What actually stops it
Stopping bot traffic requires layered defence:
Rate limiting. Limit how many checkout form submissions can come from a single IP address in a given time period. If an IP submits the form 100 times in an hour, block it. This is a server-level control, not a plugin.
CAPTCHA or challenge. Require visitors to prove they’re human before they can submit the checkout form. reCAPTCHA v3 is less intrusive than older versions. It runs in the background and flags suspicious behaviour without requiring the user to solve a puzzle.
Bot detection. Modern hosting providers can detect bot traffic patterns and block it before it reaches your site. This includes checking user agents, request patterns, and known bot IP ranges.
Payment gateway filtering. Your payment processor (Stripe, PayPal, Square) has built-in fraud detection. Use it. Enable AVS (Address Verification System) and CVV checks. Decline transactions that fail these checks.
Logging and monitoring. Keep detailed logs of checkout attempts. Monitor for patterns. If you see 500 failed transactions from the same IP range in an hour, that’s a bot attack. You need to know about it.
Honeypot fields. Add hidden form fields that humans won’t fill out but bots will. If a honeypot field is populated, reject the submission. This catches simple bots without requiring CAPTCHA.
A real example
We host an e-commerce store that was getting hit with hundreds of fake orders a day. The owner was spending hours deleting them. Their payment gateway was flagging the account for suspicious activity.
The site had no rate limiting. A bot could submit the checkout form as many times as it wanted from the same IP. There was no CAPTCHA. There were no honeypot fields. The payment gateway was accepting transactions without AVS checks.
We implemented:
- Server-level rate limiting (max 5 checkout submissions per IP per hour)
- reCAPTCHA v3 on the checkout form
- Honeypot fields on the form
- AVS and CVV checks enabled in the payment gateway
- Log monitoring to flag suspicious patterns
Fake orders dropped from 300+ a day to 2-3 a week. The ones that did get through were caught by the payment gateway’s fraud detection.
More importantly, the owner’s payment processor stopped flagging the account. Their legitimate transactions started processing more reliably.
It’s a hosting responsibility
Stopping bot traffic is partly your responsibility as a site owner, and partly your hosting provider’s. A good hosting provider will:
- Implement rate limiting at the server level
- Monitor for bot traffic patterns
- Block known bot IP ranges
- Provide tools for CAPTCHA and honeypot integration
- Keep detailed logs so you can see what’s happening
If your hosting provider can’t or won’t do these things, it’s time to switch.
If you’re running WooCommerce and seeing fake orders, this is worth taking seriously. It’s not just an annoyance. It’s a security issue that affects your business.