Why am I getting lots of small failed orders?

The short version

• The signs: many orders in a short time, small amounts, the same cheap item, nonsense names and emails, most of them failed.
• First: refund any that went through. Real cardholders will spot them and dispute them.
• Then: make sure your CAPTCHA protects the checkout your store actually uses, and turn on WooCommerce’s checkout rate limiting.
• Also: add fraud rules in your payment provider, such as blocking very small orders.
• Don’t just block an IP address. Stripe says single filters like that usually aren’t enough.

What is card testing?

Stripe’s card testing guide describes it as fraud where someone tries to work out whether stolen card details are valid, so they can use or sell the good ones. They use scripts to push many cards through a checkout quickly, often for tiny amounts that cardholders won’t notice. Your store isn’t the target. It’s the tool.

How do I know it’s happening?

Stripe lists the common symptoms:

• a spike in failed or blocked payments on the Dashboard home page and the payments list;
• a spike in card errors, often a “generic decline”;
• low-value payments with nonsensical customer names and emails.

WooCommerce’s WooPayments card testing page adds that the orders often all contain the same inexpensive item. In WooCommerce, you’ll see a run of Failed and Pending payment orders in WooCommerce, then Orders.

How do I stop it?

1. Refund the ones that succeeded

Stripe and WooCommerce both put this first. WooCommerce calls refunding suspect orders “of the utmost importance.” Each one is a real person’s card, and they will dispute it. Our guide on refunding an order shows the steps. If more than about 20 got through on WooPayments, WooCommerce says to ask WooPayments support for a bulk refund.

2. Check your CAPTCHA covers the right checkout

A CAPTCHA on the checkout stops most scripts. But WooCommerce’s December 2024 post on card testing explains a catch. Newer stores use the Checkout block, which sends orders through WooCommerce’s Store API. Some CAPTCHA plugins only protected the older checkout, so attackers went around them. The post lists patched versions of several CAPTCHA plugins. Update yours, and confirm with its maker that it covers the Checkout block and the Store API.

3. Turn on checkout rate limiting

WooCommerce’s rate limiting documentation says it’s off by default. To turn it on for checkout, go to WooCommerce, Settings, Advanced, Features, and enable Rate limiting Checkout block and Store API. It then allows 3 place-order attempts per minute from the same visitor. The documentation describes it for the Checkout block, so an older shortcode checkout relies on your CAPTCHA and provider rules instead. WooCommerce is honest that rate limiting slows attacks but doesn’t stop them fully, so use it alongside a CAPTCHA. If your store sits behind a proxy or a service such as Cloudflare, a developer needs to switch on proxy support in code, or real customers can share one limit and be blocked.

4. Add rules in your payment provider

• WooPayments: its fraud protection rules can block suspicious orders before the customer is charged. WooCommerce’s example is blocking orders under $5.
• Stripe: Radar has built-in checks, such as CVC checks, and custom velocity rules on plans that include them.
• Keep watching for a few days. WooCommerce notes attackers change tactics, and usually move on.

5. Ask your developer about the rest

Stripe says that if you use a plugin or platform, stopping card testing usually needs code-level changes, and suggests showing its guide to whoever built your checkout. Requiring an account before checkout also reduces exposure, though it adds friction for real customers.

Why does it matter?

Stripe lists the damage: disputes from the cards that went through, a higher decline rate that can make honest customers’ payments look risky even after the attack ends, extra fees, strain on your site, and sales reports full of fake customers. An attack can also trigger hundreds of failed-order emails to your inbox.

What are the common mistakes and edge cases?

• Only blocking IP addresses. Attackers rotate them.
• Turning off the payment method entirely. It stops the attack and your sales. Use it only as a short emergency step.
• Leaving the successful test charges alone. They become disputes, each with a fee.
• A CAPTCHA on the wrong form. Protecting the login page doesn’t protect checkout.
• Leaked secret keys. Stripe warns that a stolen secret key lets attackers create payments directly. Never paste payment keys into emails or support chats. If you suspect a leak, roll the keys in the provider’s dashboard.

What if this didn’t work?

• Attacks continue after CAPTCHA. Check the CAPTCHA is validated on the server for every checkout request, as Stripe recommends, and try a stricter setting or a different CAPTCHA.
• Real customers are being blocked. Loosen the rate limit or check the proxy setting.
• Payments don’t appear as orders at all. Attackers may be calling the payment provider directly. Tell your provider’s support team, and say that the transactions aren’t linked to orders.

How much does it cost, and how long does it take?

The settings and most CAPTCHA tools are free or low cost. Cleaning up a small attack, refunds included, takes an hour or two. A long one can take days of watching.

How does E-3 handle this?

On stores in our website care, monitoring flags known plugin vulnerabilities and waiting updates, and payment and CAPTCHA plugins get tested updates. If you see a burst of failed orders, tell us the time it started. A person at E-3 checks the orders and logs, turns on the protections above, and helps you work out which payments to refund. Call 814-399-4655 or email support@e3help.me.

Related questions

• What do I do when a customer disputes a charge?
• Do I need to be PCI compliant?
• How do I update WooCommerce without breaking checkout?
• Why isn’t online payment or checkout working?
• Back to the complete online store guide

Sources

1. Protect yourself from card testing (Stripe documentation)
2. Card testing attacks and the Store API (WooCommerce Developer Blog, December 18, 2024)
3. Rate limiting for the Store API (WooCommerce developer documentation)
4. Card testing (WooPayments documentation)