WooCommerce Fake Orders: Stopping Card Testing on Your Checkout

On this page 8 sections

1. What a Wave of WooCommerce Fake Orders Looks Like
2. Why Bots Target WooCommerce Checkouts and the Store API
3. The Real Cost: Authorization Fees, Gateway Flags and Account Reviews
4. Gateway-Level Defenses: Fraud Rules, Velocity Limits and CVV Checks
5. Site-Level Defenses: WooCommerce Checkout CAPTCHA, Rate Limiting and Firewall Rules
6. Cleaning up Failed Orders and Talking to Your Processor
7. A Monitoring Checklist to Catch the Next Attack Early
8. Next Steps

Key takeaways

• Most WooCommerce fake orders come from card testing: bots running stolen card numbers through your checkout to see which ones work.
• Bots often send orders straight to the Store API and other checkout endpoints, which skips protections that only run when a shopper loads the checkout page.
• No single fix holds for long. Layer gateway rules, server-side CAPTCHA, rate limits and a firewall, and keep the key controls outside WordPress so they survive plugin updates.
• If an attack hits, document it before you clean up and contact your processor early. Waiting for them to notice first usually goes worse.

If you woke up to dozens or hundreds of WooCommerce fake orders, you are probably dealing with a card testing attack. Someone is using your checkout to check stolen card numbers. This guide covers what the attack looks like, why bots go after the WooCommerce Store API and other checkout endpoints, what it costs you, and how to build layered defenses at the gateway, site and firewall level that keep working after your next plugin update.

What a Wave of WooCommerce Fake Orders Looks Like

Card testing rarely looks like a normal fraud order. A single fraudulent purchase tries to get goods shipped. Card testing is about volume: a bot submits many small authorizations to learn which stolen card numbers are still live, then sells or uses those cards somewhere else.

Common signs in a WooCommerce store:

• A sudden spike in failed or pending orders, often overnight or on weekends when nobody is watching.
• The same low-priced product in most orders, because bots pick the cheapest item.
• Names and emails that don't add up: random strings, mismatched billing names, throwaway domains or the same email with small variations.
• Billing addresses that don't match the card's country or the IP location.
• Many different card numbers tried in a short window, sometimes with the same expiration date or BIN (the first digits of the card).
• A flood of "Failed order" admin emails and new customer accounts you didn't expect.
• Activity on "Add Payment Method" in My Account, even when no order is created.

That last one surprises many store owners. If your gateway lets logged-in customers save a card, bots can register an account and test cards without ever placing an order.

Why Bots Target WooCommerce Checkouts and the Store API

WooCommerce is popular, and its checkout endpoints are predictable. Attackers write a script once and reuse it across thousands of stores.

The Store API Accepts Orders Directly

The block-based Cart and Checkout use the WooCommerce Store API, a REST interface that accepts checkout data as structured requests. The checkout route typically sits at a path like /wp-json/wc/store/v1/checkout. A bot doesn't need to load your checkout page, click buttons or run your JavaScript. It can collect a session token and send order requests straight to the endpoint.

This explains a lot of the frustration around WooCommerce Store API spam orders. A CAPTCHA widget that only appears on the checkout page does nothing if the bot never loads that page and the server never checks the CAPTCHA token on the API request.

Classic Checkout Has Its Own Endpoint

Stores on the older shortcode checkout aren't immune. Classic checkout submits through an AJAX endpoint (commonly ?wc-ajax=checkout), and bots target that too. If you switched from classic to block checkout, or the reverse, your protections may only cover one of them.

Why "Just Block the Endpoint" Can Backfire

Blocking the Store API checkout route sounds like a quick fix. If your store uses the block-based checkout, blocking it breaks checkout for real customers. Some express payment buttons and extensions also depend on these routes. Restrict an endpoint only after you confirm which checkout your store uses, and test a real purchase afterward.

The Real Cost: Authorization Fees, Gateway Flags and Account Reviews

Fake orders don't ship anything, but they still cost you money and put your account at risk.

If you aren't sure what you pay for each authorization attempt, our breakdown of WooCommerce transaction fees per sale shows where those charges appear on a statement.

Gateway-Level Defenses: Fraud Rules, Velocity Limits and CVV Checks

Your payment gateway sees every attempt, whichever endpoint the bot used. That makes it the most reliable place for controls, and gateway settings aren't overwritten when you update WordPress plugins.

Most gateways, including the payment gateways MannyPay supports such as Authorize.net and NMI, offer configurable fraud filters. Names and options vary, so check what your gateway provides. Look for:

1. Require CVV and decline on mismatch. Card testers often have numbers without valid security codes. Rejecting CVV failures stops many attempts.
2. Use AVS (address verification). Decide whether to decline or review when the address or ZIP doesn't match. Be careful with international customers, whose banks may not support AVS the same way.
3. Set velocity limits. Cap attempts per IP address, per card, per email and per time window. Card testing depends on speed, so even modest limits slow it down sharply.
4. Flag clusters of declines. Some gateways can block an IP or device after repeated declines.
5. Turn on 3-D Secure. Adding 3-D Secure authentication on risky transactions adds a cardholder check that bots usually can't pass.
6. Consider a minimum order value during an attack. If bots target a low-priced item, temporarily raising the minimum or hiding that product can make your store less useful to them.

Gateway rules are your floor. Even if a plugin update quietly disables your CAPTCHA, these rules still screen every attempt.

If tighter rules cause legitimate declines, our guide to fixing WooCommerce payment failed errors explains how to tell fraud blocks from ordinary bank declines.

Site-Level Defenses: WooCommerce Checkout CAPTCHA, Rate Limiting and Firewall Rules

Gateway rules screen attempts. Site-level controls stop bad requests from reaching the gateway at all, which also cuts the authorization fees they trigger.

Add a CAPTCHA That Verifies on the Server

A WooCommerce checkout CAPTCHA only works if two things are true:

• It covers the checkout your store actually uses: block checkout, classic checkout or both.
• The server checks the CAPTCHA token on the order request itself, including Store API requests, rather than only showing a widget in the browser.

Before you rely on a plugin, ask its developer whether it protects the Store API checkout route. Then test it. Your developer can try a request without a valid token and confirm it gets rejected. Invisible or low-friction challenges usually hurt conversion less than puzzle-style ones.

Protect the Add Payment Method page and account registration as well. If you don't need saved cards, consider turning that feature off.

Rate-Limit Checkout Endpoints

Rate limiting caps how many requests one source can send in a set period. Apply it to:

• The Store API checkout route
• The classic checkout AJAX endpoint
• The Add Payment Method page
• Account registration

WooCommerce has documented an opt-in rate-limiting option for Store API checkout requests that a developer can enable. Confirm the current method in WooCommerce's developer documentation. Hosting-level or CDN-level rate limiting is often stronger, because it stops traffic before it reaches WordPress.

Use a Web Application Firewall

A WAF at your host or CDN can:

• Challenge or block high-volume requests to checkout paths.
• Block or challenge countries you don't sell to.
• Filter known bad bots, data center IP ranges and suspicious user agents.
• Apply emergency rules during an active attack, such as challenging every checkout request for a few hours.

Tighten the Checkout Itself

• Temporarily require accounts. Turning off guest checkout during an attack adds friction for bots. It adds friction for shoppers too, so weigh the tradeoffs in our comparison of guest checkout vs. forced accounts.
• Review your "Hold stock" setting under WooCommerce inventory settings so unpaid fake orders release stock quickly.
• Restrict selling and shipping countries to the places you actually serve.

Making Defenses Survive Plugin Updates

Card testing defenses often fail quietly after an update changes how checkout renders. To keep them working:

• Put core controls outside WordPress: gateway fraud rules, CDN or host firewall, and server-level rate limits.
• Keep custom code in a child theme or snippets plugin, never in edited WooCommerce core files.
• After every WooCommerce, theme or gateway plugin update, place a test order and confirm the CAPTCHA still blocks unverified requests.
• Write down which checkout type you run and which endpoints each control covers.

Cleaning up Failed Orders and Talking to Your Processor

Once the attack slows, clean up in a set order.

1. Document first. Export the affected orders with timestamps, IP addresses, emails and amounts. Save gateway logs. Your processor may ask for these.
2. Void or refund anything that went through. Check the gateway for approved test charges. Void open authorizations where you can, and refund captured ones so they don't turn into disputes.
3. Bulk-remove fake orders. Filter by status (failed, pending, cancelled) and date range, then trash them after you have exported the records.
4. Delete spam customer accounts created during the attack.
5. Rotate credentials if anything looks off. Change gateway API keys and admin passwords if you see signs of access beyond checkout abuse.

Then contact your processor proactively. Explain when the attack started, roughly how many attempts were made, what you have refunded and which controls you have added. Processors generally respond better to a merchant who reports the problem and shows a fix than to one they discover through their own alerts. If you're reconsidering your setup after an attack, our checklist for choosing a WooCommerce payment gateway covers the fraud tools to ask about.

Illustrative example: A small WooCommerce candle shop sees 400 failed orders for its cheapest sample item between 2 a.m. and 5 a.m. The owner exports the order data, refunds the handful of approvals, adds gateway velocity limits and a firewall challenge on checkout paths, and emails the processor that morning with a summary. The next attempt a week later is blocked at the firewall.

A Monitoring Checklist to Catch the Next Attack Early

Attackers often come back to stores that worked for them once. Watch for these signals:

• [ ] Daily count of failed and pending orders compared with your normal baseline
• [ ] Decline rate in your gateway dashboard
• [ ] Spikes in orders for your lowest-priced product
• [ ] New customer registrations at unusual hours
• [ ] Add Payment Method activity
• [ ] Mismatches between billing country, shipping country and IP location
• [ ] Firewall and server logs showing repeated hits on checkout endpoints
• [ ] Gateway alerts for velocity rule triggers
• [ ] A test order after every plugin update

Set up alerts where you can, so a spike at 3 a.m. reaches your phone. For a broader look at bot defense across platforms, see our guide to stopping card testing attacks on any checkout.

Next Steps

WooCommerce fake orders are a symptom of card testing. The fix is layers, not a single plugin. Start with gateway rules that screen every attempt, add a server-verified CAPTCHA that covers the Store API, rate-limit and firewall your checkout endpoints, and re-test after every update.

If you want help reviewing your gateway setup or fraud tools, MannyPay offers WooCommerce payment processing and online payment acceptance for e-commerce merchants. Request a free quote, and a MannyPay specialist will respond within one business day.

ME

About the author

MannyPay Editorial Team

Beyond the Swipe's editorial desk researches the publication's guides and news and cites its sources in every article. Articles reviewed by a named MannyPay editor carry that editor's byline.

This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.