Fake Orders and Card Testing: Signs and Fixes

If your store suddenly gets lots of small orders that fail, or orders from strange emails, you are most likely seeing card testing: criminals using your checkout to find out which stolen card numbers still work, and you can slow it down today with a checkout CAPTCHA, rate limits and your payment provider's fraud rules.

This post is for owners of small online stores, especially WooCommerce, but most of it applies to any shop. You will learn how to tell card testing from fake orders and normal trouble, what to check first, and a short list of fixes you can do in an afternoon.

What card testing actually is

Card testing (also called carding) is when an attacker has a list of stolen card numbers and does not know which ones are still active. They use a real checkout, like yours, to try small payments. A payment that goes through tells them the card is live, and they then use it somewhere else for something bigger.

Security researchers file this under automated threats. OWASP, the open web security nonprofit, lists it as OAT-001 Carding in its Automated Threats to Web Applications project. Stripe also explains the pattern in its card testing guide.

The key point: this usually does not mean your site was hacked. Attackers are using the front door that every customer uses. That is why a CAPTCHA, rate limit or fraud rule can work even if your site is fully up to date.

Signs of a card testing attack

You will rarely see one clue. You will see several at once, usually in a burst.

• Many failed or pending orders in a short time. Dozens in an hour when you normally get a few a day.
• Small amounts. The cheapest product, a free product, or a tiny add-on, bought again and again.
• Odd emails. Random letters (like xk3jq9@example.com), many addresses at one domain, or the same address with small changes.
• Junk names and addresses. Billing names that do not match, or obviously fake street details.
• Many different cards from one place. Your payment dashboard shows lots of declines with codes like card declined, incorrect CVC (the 3 or 4 digit security code) or incorrect postal code.
• Odd timing. Traffic at 3 a.m. in your time zone, or exactly spaced requests.
• Tell-tale gateway emails. Your provider warns you about a spike in declines or disputes.

Card testing, fake orders or something else?

The fix depends on what you are looking at. Use this table.

Step 1: Check the evidence (10 minutes)

Before changing settings, confirm what is happening.

1. In WordPress, open WooCommerce > Orders and filter by Failed and Pending payment. Look for clusters in time, repeated amounts and strange emails.
2. Open your payment dashboard (Stripe, PayPal, Square or similar) and look at declines. Note the decline reasons.
3. If you have server access, count checkout requests per visitor IP address in your access log. This command works for common Apache or Nginx logs, where the IP is the first field:

grep "POST" access.log | grep -E "wc-ajax=checkout|wc/store" | awk '{print $1}' | sort | uniq -c | sort -rn | head

One caution: behind Cloudflare or another proxy or CDN (a service that sits in front of your site), the first log field may be the proxy's IP, not the visitor's. If the top IPs belong to Cloudflare or your host's proxy, do not block them. That would block real customers. Use the real visitor IP header or Cloudflare's own logs instead.

If a few real visitor IPs show hundreds of attempts, blocking those addresses can help. If you see hundreds of different IPs with one or two attempts each, the attacker is rotating addresses, and you need CAPTCHA and gateway rules more than IP blocks.

Step 2: Turn on your payment provider's fraud tools

Your gateway sees patterns across many merchants, so use it first.

• Stripe: Go to Dashboard > Radar > Rules and review the default rules. Turn on rules that block or review payments when the CVC check or postal code check fails, where offered. Custom rules may need a paid Radar plan, so check Stripe's Radar rules docs for what your account includes.
• Other gateways: Look for settings named fraud filters, address verification (AVS), CVC required, or 3D Secure (the extra bank check step). Requiring these makes bulk testing harder.
• Shopify stores: Checkout has built-in bot protection, so focus on the fraud and payment settings of your payment provider and review risky orders before fulfilling them.

Also contact your provider if the attack is large. Ask them before you refund or cancel hundreds of test charges at once. They often have specific steps, and a high decline rate can affect your standing with them.

Step 3: Add a CAPTCHA to checkout

A CAPTCHA is a small check that tries to tell humans from scripts. Many are now invisible to real shoppers.

• Cloudflare Turnstile is a free option that rarely shows puzzles.
• On WooCommerce, plugins such as Simple Cloudflare Turnstile can add it to the checkout, login and registration forms. Check that the plugin supports your checkout type (classic or block checkout) before relying on it.
• Google reCAPTCHA is another option. Pick one and test a real purchase afterwards.

Also protect the add to cart, login and registration forms if bots use them. A CAPTCHA on checkout alone can be bypassed if attackers can hit other steps.

Step 4: Rate limit the checkout

A rate limit caps how many requests one visitor can make in a short time. Real shoppers pay once. Bots try dozens of times.

If your site is behind Cloudflare, create a rule under Security > WAF > Rate limiting rules (see the Cloudflare rate limiting docs). Use this expression to target WooCommerce checkout submissions:

(http.request.method eq "POST" and (http.request.uri.query contains "wc-ajax=checkout" or http.request.uri.path contains "/wc/store/v1/checkout"))

Count requests by IP address. A sensible starting point is more than 5 requests in 10 seconds, with the action set to Block and a short timeout. Limits and timeouts available depend on your Cloudflare plan, so check what yours allows.

Why Block and not Managed Challenge? A Managed Challenge usually cannot be shown on background (fetch/XHR) checkout requests, so a real shopper who trips the limit may just see a failed checkout with no explanation. Block (with a short timeout) is the more reliable action for this endpoint. If you want a challenge, use a Managed Challenge on the checkout page itself.

Treat 5 requests in 10 seconds per IP as a starting point, not a rule. Several shoppers can share one IP address (an office, a school or a mobile network), and a real customer retrying a declined card can send a few requests quickly. Watch for real customers being blocked and raise the limit if it happens.

No Cloudflare? The Wordfence plugin has a coarse, site-wide backstop under Wordfence > Firewall > All Firewall Options > Rate Limiting. It throttles requests per minute by visitor type (for example humans, crawlers and pages not found), so it cannot target only the checkout URL the way the Cloudflare rule does. Set the thresholds high enough that real customers and search engines are not blocked, and test a normal purchase afterwards. Your host may also offer rate limiting.

Rate limits per IP will not stop attackers who rotate thousands of addresses. Use them together with CAPTCHA, not instead of it.

Step 5: Make tiny test purchases less useful

These changes cost you almost nothing and remove the attacker's favourite targets.

• Set a minimum order amount that suits your catalogue. In WooCommerce this takes a small code snippet. Add it with a code snippets plugin, not by editing your theme:

add_action( 'woocommerce_check_cart_items', function () {
    $min = 10; // change to suit your store
    if ( WC()->cart && WC()->cart->get_subtotal() < $min ) {
        wc_add_notice( sprintf( 'Minimum order is %s.', wc_price( $min ) ), 'error' );
    }
} );

• Look at free or very cheap products. Attackers love a $0.50 item or a free sample with a payment step. Limit quantity or require an account for these.
• Require an account (WooCommerce > Settings > Accounts & Privacy, untick guest checkout). This adds friction for real shoppers, so use it only if the attack is serious.
• Block obvious patterns such as throwaway email domains you never see from real customers. Avoid blocking whole countries unless you are sure you have no customers there.

Step 6: Keep an eye on it

Once it calms down, set simple alerts.

• Turn on your gateway's email alerts for spikes in declines or disputes.
• Check the Failed orders list weekly for a minute. A sudden jump is your early warning.
• Keep WordPress, WooCommerce and your plugins updated, so attackers have fewer other ways in. Our guide to whether your website is hackable explains what to check.

If you also see unknown admin users, changed files or strange redirects, that is a different problem. Read what to do if your website is hacked.

Where a security check helps

Card testing is a fraud problem and a website problem at the same time. Your gateway handles the money side. The website side includes things like whether old plugins are exposed and whether basic protections are in place. Whether your checkout and API endpoints accept unlimited requests is something a person has to test by hand, so that item belongs to the manual Circuit audit, not the free check.

You can start with our free website security check, which is a passive look at your site from the outside with no card or login. It does not test rate limits, and it will not tell you whether a specific card was tested. It shows what an outsider can see.

Next step

These fixes handle the usual wave, but they are not a guarantee, and no setup is perfect. If you want a person to look at your whole store, including checkout, plugins and exposed endpoints, the Circuit audit is a one-time $49 manual review with a written report and exact fixes. It is a small-site audit, not an enterprise pentest or a compliance certification. See the pricing page if that sounds useful.

Key takeaways

• Many small failed orders plus gibberish emails in a short burst usually means card testing, not a hacked site.
• Turn on your payment provider's fraud rules first (CVC and postal code checks, Stripe Radar rules, 3D Secure).
• Add a CAPTCHA such as Cloudflare Turnstile to checkout, login and registration.
• Rate limit checkout submissions (for example, a starting point of 5 requests in 10 seconds per IP, using Block with a short timeout), and expect attackers to rotate IPs.
• Remove easy targets: set a minimum order, restrict free items, and check your Failed orders weekly.