WooCommerce Security
On this page
- What card testing is (and why your store was chosen)
- Why it matters even though the orders "failed"
- Recognizing the signature
- What an attack looks like hour by hour
- Common mistakes when responding
- Stop it: the immediate response (first hour)
- 1. Put friction in front of checkout
- 2. Enable Store API rate limiting
- 3. Tighten your gateway's fraud rules
- 4. Block obvious sources at the edge
- 5. Temporarily hide the target
- Clean up afterwards
- What to tell your payment gateway
- Prevent the next one
- Seeing an attack within the hour, not the morning after
- Card testing response checklist
You open WooCommerce in the morning and the orders list is unrecognizable. Hundreds of new orders arrived overnight, almost all of them Failed. They’re for the cheapest product you sell. The names look random, the email addresses are nonsense, and the billing addresses don’t match anything.
Then your payment gateway emails you about unusual activity.
This is a card testing attack, and it’s one of the most common complaints in WooCommerce communities. Threads with titles like “Spam orders, at my wits’ end” turn up regularly on r/woocommerce and the WordPress.org forums. It’s unsettling, but it’s well understood, and there’s a clear playbook for stopping it.
What card testing is (and why your store was chosen)
Criminals buy stolen card numbers in bulk. Many of those cards are already cancelled or blocked. Before they use or resell them, they need to know which ones still work. The cheapest way to find out is to attempt small purchases on real stores and see which payments go through.
Your store wasn’t chosen because of anything you sell. It was chosen because it:
- has a cheap product (a low-value charge attracts less attention),
- has a checkout that can be scripted (no CAPTCHA, no rate limiting),
- uses a major gateway whose responses are easy to interpret.
WooCommerce’s developer blog has noted that attackers have targeted the WooCommerce Store API directly: the REST endpoints behind the block-based cart and checkout. This works even on stores that don’t use the Checkout block, because the endpoints exist on every modern WooCommerce install. Bots skip your checkout page entirely and talk straight to the API.
Why it matters even though the orders “failed”
It’s tempting to think failed orders are harmless. They aren’t:
- Gateway fees. Some gateways charge per authorization attempt or for fraud screening, even when the payment fails.
- Account risk. A flood of declines looks bad to your gateway. Stripe and others may restrict or review your account, and in serious cases pause payouts.
- Disputes later. Some test charges succeed. When real cardholders spot them, they dispute them, and you pay a dispute fee (Stripe charges $15 per dispute in the US, win or lose) on top of refunding.
- Polluted data. Hundreds of junk orders distort your reports, analytics and stock reservations.
- Emails. Depending on your settings, failed-order emails can flood your admin inbox.
- Server load. Thousands of checkout requests can slow the site for real customers.
Recognizing the signature
Card testing has a very recognizable pattern:
| Signal | What you’ll see |
|---|---|
| Volume | A sudden spike, often overnight, far above your normal hourly order count |
| Status | Mostly Failed, with a few Processing (the cards that worked) |
| Products | The cheapest item, or a single low-priced product over and over |
| Customer details | Random or mismatched names, emails and addresses; often guest checkouts |
| Payment notes | Declines with reasons like card declined, incorrect CVC, insufficient funds |
| Origin | Many different IPs, or bursts from data-centre ranges |
| Timing | Requests seconds apart, at hours your real customers don’t shop |
If you see most of the first four, assume it’s card testing and act now. You can confirm the details later.
What an attack looks like hour by hour
Attacks vary, but a typical overnight incident on a small store runs something like this:
- 01:40: The first few orders arrive for a $3 product. Two fail with card declined, one succeeds. Nobody notices: it’s the middle of the night, and three orders is unremarkable.
- 02:00–03:00: The bot speeds up once it’s confirmed the checkout can be scripted. Dozens of attempts an hour, mostly failures, from rotating IP addresses.
- 03:00–07:00: Hundreds of attempts. The admin email inbox fills with failed-order notifications. Your gateway’s risk systems start to notice.
- 07:30: You wake up to the inbox, the orders list, and perhaps an email from your gateway.
Every hour between 01:40 and 07:30 was another batch of stolen cards validated on your store, another set of potential disputes, and another notch against your account’s risk profile. Shortening that window is the single biggest thing you can do to reduce the damage.
Common mistakes when responding
- Deleting the orders before refunding the successful ones. You lose the easiest list of charges to refund. Export first, refund, then clean up.
- Refunding in the gateway dashboard only. It works for the money, but WooCommerce still shows paid orders, which distorts reports and can leave orders in Processing to be shipped. Refund from the WooCommerce order where you can.
- Blocking by country or IP only. Attackers rotate IPs and use proxies in your own country. Use it as a supplement, not a fix.
- Turning off the gateway entirely. It stops the attack, but it also stops real customers. CAPTCHA and rate limiting usually let you stay open.
- Assuming it’s over because it stopped. Attackers often pause and return. Keep defences on.
Stop it: the immediate response (first hour)
1. Put friction in front of checkout
Turn on a CAPTCHA that protects the checkout and the Store API. This matters. WooCommerce’s developer team found that some CAPTCHA plugins didn’t protect the Checkout block or Store API, so bots skipped them entirely, and worked with several plugin authors to patch them. Make sure your CAPTCHA plugin is up to date and explicitly supports block checkout and the Store API.
2. Enable Store API rate limiting
WooCommerce includes rate limiting for the Store API, but it’s off by default. Developers can enable and configure it with the `woocommerce_store_api_rate_limit_options` filter. WooCommerce 9.6 added stricter rules for the place-order endpoint that can be configured from the admin, and 9.8 added a filter for using a custom fingerprint rather than IP address. If your store sits behind a proxy or CDN, enable proxy mode so you don’t rate-limit all your real customers as one IP.
3. Tighten your gateway’s fraud rules
In Stripe, review Radar rules: block payments where the CVC or postcode check fails, and consider blocking or reviewing high-risk payments. Other gateways have equivalent risk settings. Tell your gateway’s support team you’re under attack. They see this daily.
4. Block obvious sources at the edge
If your host or CDN offers a WAF, add rules or challenges for the checkout and Store API paths, and block data-centre ranges if the attack comes from them.
5. Temporarily hide the target
If the attack hammers one cheap product, temporarily raise its price, set it to private, or require login for checkout until defences are in place.
Clean up afterwards
- Refund any successful test charges. Find the few Processing orders that match the attack pattern, verify them against the gateway, and refund them through the WooCommerce order (so both systems record it). Proactively refunding is cheaper than fighting the disputes that will otherwise arrive.
- Restore stock. Check that cancelled or failed junk orders aren’t still holding stock.
- Delete or trash the junk orders once refunded, so they stop polluting reports. Export a list first for your records.
- Check customer accounts. If the attack created accounts, remove them.
- Tell your gateway what you’ve done. It helps your account standing.
- Review your email settings so a future attack doesn’t flood your inbox.
What to tell your payment gateway
Gateways deal with card testing constantly, and a clear, early message from you helps both your account standing and their response. Include:
- When it started and whether it’s still going
- Roughly how many attempts and how many succeeded
- Which product was targeted and its price
- What you’ve done: CAPTCHA enabled, rate limiting on, fraud rules tightened, successful charges refunded
- A request for any account-level protections they can add while things settle
Keep a copy. If your account is later reviewed because of the spike in declines, a record showing you acted quickly and responsibly is useful.
It’s also worth asking whether your gateway offers built-in card-testing protection you haven’t switched on. Several gateways and payment plugins now include specific protections against bursts of low-value attempts, and they’re often off by default or tucked away in advanced settings.
Prevent the next one
- Keep CAPTCHA and rate limiting on permanently. Attackers return to stores that worked once.
- Keep WooCommerce updated. Store API protections have improved release by release.
- Watch your order volume. The earlier you notice an attack, the fewer cards get tested on your store and the smaller the clean-up.
- Set up alerts. An attack that starts at 2 a.m. shouldn’t run until 9 a.m.
That last point is the one most stores miss. Every defence above is something you turn on after you notice. The size of the damage depends almost entirely on how long the attack runs before someone sees it.
Seeing an attack within the hour, not the morning after
Ordafide Pro includes order volume anomaly detection. Every hour, it compares the current hour’s order count with comparable past hours, using median-based statistics so that genuinely busy periods like a sale don’t distort the baseline. It flags both spikes, the typical shape of a card testing burst, and drops, which usually mean checkout is broken. Findings resolve themselves when volume returns to normal.
Combined with Pro’s alerts (Slack, SMS via Twilio, email, or a signed webhook into Discord, Microsoft Teams or PagerDuty), with severity routing and throttling, an overnight spike becomes a message on your phone while the attack is still small.
Pro’s read-only gateway reconciliation with Stripe, PayPal, Square, Mollie and Razorpay also helps afterwards. It shows any money with no order and any amount disagreements, so you can be sure you’ve found every successful test charge, including ones that never produced a clean WooCommerce order.
The free Ordafide plugin won’t detect an attack in progress (that needs volume monitoring), but its duplicate charge and refund mismatch checks help verify the clean-up: that refunds were recorded correctly, and that no refunded order is still sitting in Processing waiting to be shipped.
Ordafide is not a fraud-prevention firewall and doesn’t block requests. It’s the alarm that tells you to put the firewall up. Use it alongside CAPTCHA, rate limiting and your gateway’s fraud rules.
Card testing response checklist
Right now
- [ ] CAPTCHA on checkout, confirmed to protect block checkout and the Store API
- [ ] Store API rate limiting enabled (proxy mode on if behind a CDN)
- [ ] Gateway fraud rules tightened; gateway support informed
- [ ] WAF challenge on checkout/Store API paths
Within 24 hours
- [ ] Successful test charges identified and refunded through WooCommerce
- [ ] Stock checked and restored
- [ ] Junk orders exported, then removed
- [ ] Junk customer accounts removed
Permanently
- [ ] WooCommerce, gateway and CAPTCHA plugins kept updated
- [ ] Order volume monitored with alerts for spikes
Frequently asked questions
Why am I getting hundreds of failed orders in WooCommerce?
Almost always a card testing attack: bots using stolen card numbers to find which ones work, typically by buying your cheapest product.
Do failed card testing orders cost me money?
They can: gateway fees, disputes on test charges that succeeded, possible account restrictions, and clean-up time.
Does CAPTCHA stop card testing on WooCommerce?
It helps a lot, but only if it protects the Store API and block checkout. Some CAPTCHA plugins historically didn't, so keep yours updated and check it supports both.
Is Store API rate limiting on by default?
No. It has to be enabled. WooCommerce 9.6+ makes checkout rate limits configurable in the admin.
Can Ordafide block card testing?
No. Ordafide Pro *detects* unusual order spikes and alerts you quickly. Blocking is done by CAPTCHA, rate limiting, your WAF and your gateway's fraud tools.