A client emails: "we've got hundreds of failed orders, is the payment gateway broken?" The gateway is almost certainly fine. What is happening is worse, it is documented by WooCommerce itself, and the damage will outlast the attack by months. Let's read the three patterns properly — because each one means something completely different, and two of them are invisible in the reports your client actually looks at.
First, what "failed" actually means
WooCommerce is precise about this, and the distinction matters for everything below:
- Pending payment — "The order has been received, but no payment has been made." The customer hasn't paid yet; often they are mid-flow, or wandered off.
- Failed — "The customer's payment failed or was declined, and no payment has been successfully made." A payment was attempted and rejected.
So a failed order requires someone to have reached the payment step and been turned down. That single fact is what lets you diagnose all three patterns.
Pattern 1: a spike of failed orders — you're being used to test stolen cards
WooCommerce has an entire document about this, which tells you how common it is:
"Card testing is a type of fraud where the someone obtains a large amount of stolen credit card data, and then attempts to determine which of those cards are valid… multiple low-value purchases, each with a different card, to avoid detection."
The sign to watch for: "a large increase in the number of orders being assigned the Failed status" — hundreds or thousands within a short timeframe.woocommerce.com — preventing and responding to card testing attacks
Your client's checkout is being used as a validation service for a batch of stolen cards. The bots don't want the product. They want to know which numbers still work, so they can be sold or spent elsewhere. WooCommerce's own developer blog notes the attacks now hit the Store API checkout endpoint directly, rotating through IPs — "100 checkouts/minute, all from different IPs".
"But nothing was actually charged, so what's the harm?"
This is where store owners — and, honestly, a lot of agencies — get it wrong. The failed payments are not the damage. They are the exhaust.
- Your decline rate is now poisoned — permanently. Stripe's documentation states that an elevated decline rate persists after the attack ends: card issuers have learned to distrust this merchant. Meaning your client's real customers start getting declined, weeks later, for no reason they will ever understand.
- Some cards work. Those become real charges to real victims, who file chargebacks. Disputes cost fees and count against you.
- Fees may not come back. WooCommerce's own guidance notes the payment provider "still may not refund the transactions fees for those transactions" even after you refund the fraudulent payments.
- PayPal can simply switch you off. Their Payflow carding-prevention module monitors for high declines and, when thresholds are hit, blocks the account and declines all transactions until it is manually unblocked. And PayPal states plainly that merchants "are responsible for any transactional fees imposed by PayPal or their bank that result from carding attacks".
- Card-network monitoring programs. Sustained dispute and fraud ratios pull merchants into Visa and Mastercard monitoring programs, where fines run into five and six figures.
- Your domain's email reputation takes friendly fire. WooCommerce sends a failed-order notification to the "customer" too. Those are stolen identities and junk addresses — so your client's mail server sprays hundreds of undeliverable notifications, and the bounce rate does what bounce rates do to sender reputation. The same domain that also sends order confirmations to real buyers.
So the answer to "nothing was charged, what's the harm" is: your client's ability to accept money in the future has just been degraded, and they will feel it long after the failed orders stop appearing.
The part that makes this genuinely dangerous
Here is the fact that turns an incident into a catastrophe. From WooCommerce's Analytics documentation:
"Pending payment, Cancelled and Failed order statuses are excluded [from Analytics] while Processing, On hold, and Completed order statuses are included."woocommerce.com — WooCommerce Analytics
Read that again with the attack in mind. Hundreds of failed orders are pouring in — and the store's revenue reports show nothing at all. The one screen the owner checks is, by design, blind to exactly this event. The only native signal is a flood of individual "failed order" emails, one per attempt, which is precisely the kind of noise a busy person mutes or filters into a folder.
And the built-in defence is off. WooCommerce's Store API rate limiting is disabled by default; a strict limit on the place-order endpoint only arrived in version 9.6 and must be turned on by hand. Their own blog admits IP-based limiting isn't enough against rotating IPs anyway.
Pattern 2: a rise in pending — the gateway can't talk back
A different shape entirely: orders pile up in pending payment rather than failed. That is not a decline problem, because declines produce failures. It means the loop between the payment provider and the site is broken — most commonly an undelivered webhook. The customer paid; the provider took the money; the site never heard back.
This one has teeth because of a default nobody remembers: Hold stock, 60 minutes out of the box. A pending order that isn't confirmed within that window is automatically cancelled and its stock released. So the sequence is: customer pays → webhook never lands → order sits pending → an hour later WooCommerce quietly cancels it. The money is at the payment provider. The order is gone from the store. Nobody is looking for it.
Pattern 3: silence — the pattern everyone misreads
Zero failed orders. Zero orders. A calm, clean order list.
Owners read this as "quiet week". It is often the most expensive state of the three, and here is the logic that proves it: an order cannot become failed if the customer never reaches the payment step. No orders and no failures means nobody is even getting as far as paying. The likely causes are the ones WooCommerce lists in its own troubleshooting: a plugin or theme update that broke the checkout, expired API keys, a payment method that got switched off, a gateway left in test mode.
And the cruel part: because there are no orders, there are no order emails either. The absence of bad news looks exactly like a peaceful day. There is no native mechanism in WooCommerce that tells you "no orders for three days, and you usually get twelve" — the system only reports things that happen. A thing that stops happening is not an event.
Reading the patterns
Notice the column on the right. Every failure mode in this table is invisible in the report your client trusts. Only the last row shows up — the one where nothing is wrong.
What monitoring this actually looks like
You do not need machine learning. You need two numbers, compared against the store's own history — and this is exactly what our WooCommerce checks do from inside the store:
- Failed-order share against the store's own baseline. Not an absolute threshold — a store with cash-on-delivery or aggressive fraud rules lives with a steady failure rate, and alerting on that would be noise. We compare the last 24 hours against the same store's seven-day norm, with a floor of three failures so that statistics mean something. Three times the usual rate → critical. That fires on a card-testing attack within the hour, long before anyone opens the order list.
- Order drought against the store's own baseline. Zero orders in 24 hours is only a signal if this store normally sells: we require an average of at least three orders a day over the previous fortnight before we say a word. A store doing two orders a week never gets woken up.
Plus the checks that catch the cause rather than the symptom: is a live payment gateway sitting in test mode, does the checkout page still render, and a daily smoke run of the order pipeline that proves an order can still be created at all.
The uncomfortable summary
WooCommerce will happily email your client three hundred times while bots grind stolen cards through their checkout, and show a perfectly clean revenue dashboard the whole time. It will let a paid order be silently cancelled because a webhook didn't land. And it will never, ever tell anyone that the orders stopped.
None of that is a bug — the platform reports events, and these are non-events, absences, and statuses it deliberately excludes from reports. But if you are the agency whose client's decline rate is now permanently worse, "it wasn't technically a bug" is not a conversation you want to be having.
FAQ
Why does my store suddenly have hundreds of failed orders?
Almost always card testing. WooCommerce documents it: attackers with stolen card data use a store's checkout to find which cards still work, making many low-value attempts. Their stated tell is "a large increase in the number of orders being assigned the Failed status" — hundreds or thousands in a short timeframe.
Is it harmful if all the payments failed?
Yes, and the damage outlives the attack. Stripe states the elevated decline rate persists afterwards — your real customers start getting declined. Some cards work and become chargebacks. Fees on fraudulent payments may not be refunded. PayPal's Payflow carding module can block the account entirely. And card-network monitoring programs carry fines into six figures.
Does WooCommerce Analytics show failed orders?
No — Pending payment, Cancelled and Failed are excluded by default. A card-testing attack producing hundreds of failed orders is invisible in the revenue reports the owner actually reads.
What does it mean when orders drop to zero?
Usually a dead checkout. An order can't be marked failed if nobody reaches payment — so no orders and no failures means something broke earlier. And with no orders, there are no emails either: silence looks exactly like a quiet week.
Originally published at pingvera.com.
Originally published at pingvera.com.
Top comments (0)