Failed orders with Origin "Unknown" in WooCommerce: what it means and what to do

A guide for store owners. Updated October 22, 2026. Settings are named as in WooCommerce 11.

You open WooCommerce, Orders and find a column of Failed orders you don't recognize. They're minutes apart, often for the same cheap product, and the Origin column says Unknown on almost every one. Your inbox has an email for each: [Your store]: Order #1234 has failed.

That pattern is the classic sign of card testing: a bot running stolen card numbers through your checkout to find the ones that still work. But Unknown on its own doesn't prove it, and blocking every Unknown order would turn away real customers. Here's what the label means, how to tell, and what to do now.

What the Origin column shows

Since version 8.5, WooCommerce records where each order came from. It calls this Order Attribution, and it's on unless someone turned it off (in WooCommerce, Settings, Advanced, Features). A small script in the shopper's browser notes how they arrived and sends it along with the order. You see it in the Origin column of the Orders list, and in the Order attribution box on each order's screen:

• Direct: the shopper typed your address or used a bookmark.
• Organic: Google, Referral: ... or Source: ...: a search engine, a link on another website, or a link with campaign tags on it.
• Web admin: you or your staff made the order in WordPress.
• Unknown: the order came in with none of this.

What "Unknown" means, and what it doesn't

Unknown means one thing for sure: no attribution came in with the order. A card-testing bot that sends orders straight to WooCommerce, to ?wc-ajax=checkout (the classic checkout) or to the Store API behind the checkout block, never opens your shop in a browser. The script never runs, so its orders say Unknown. That's why a card-testing run shows up as a wall of them.

Real orders can say Unknown too:

• The shopper's ad blocker or privacy browser stopped the script.
• Your cookie banner works through the WP Consent API, and the shopper didn't accept marketing cookies. WooCommerce then sends no origin.
• Your theme or a checkout plugin builds its own checkout page without the WooCommerce hooks the attribution is added through.
• The order was made by another plugin, an app or the REST API, not by your checkout.

It works the other way round as well: Direct doesn't prove a real shopper. The browser sends the origin with the order, so a bot can send any origin it likes. Treat Unknown as a hint, not proof.

Signs it's card testing

• Many failed orders in a short time, minutes or seconds apart, often at night.
• The same cheap product, or tiny amounts.
• Guest orders with names and email addresses that look made up, or one name with a different card each time.
• Unknown origin on most of them.
• The order notes (your payment plugin usually writes the reason a payment failed there) show declined cards, again and again.

If the failed orders have real names you recognize, from customers who have ordered before, it's more likely a payment problem. Check your payment plugin's settings and logs, or ask its support.

Why one bot means hundreds of orders and emails

WooCommerce creates the order before it tries the payment. When the card is declined, the order is marked Failed, and WooCommerce sends its Failed order email to your admin address. So every stolen card a bot tries leaves one failed order and one email behind.

Under attack right now? Get free help, by email, from a person.

What to do in the next hour (free)

1. Find any that went through. Look for orders from the same burst that are Processing or Completed. Don't ship them; refund them. Those cards are stolen, and their owners will dispute the charges.
2. Turn on your payment provider's fraud rules. In Stripe, open Radar and turn on blocking for payments that fail the CVC or postal code check. PayPal and others have similar settings.
3. Turn on WooCommerce's own checkout limit. In WooCommerce, Settings, Advanced, Features, turn on Rate limit Checkout (recent WooCommerce versions have it; it's off by default). It allows 3 checkout tries a minute from each shopper. That slows a bot down, though one that switches addresses gets through.
4. Look for a bot setting in your payment plugin. Some payment plugins have added their own protection, such as a CAPTCHA at checkout. Update the plugin and check its settings.
5. Quiet the emails, if you need to. In WooCommerce, Settings, Emails, open Failed order. You can send it to another address under Recipient(s), or untick Enable this email notification. That stops the emails, not the bots, and a failed order email is often your first warning of the next attack, so turn it back on afterwards.
6. Keep the failed orders for now. They're your record of the attack if your payment provider asks. Later, filter the Orders list by Failed, select them and choose Move to Trash.
7. Tell your payment provider. They have seen this before, they can help, and it shows you're dealing with it.

Why "block orders with Unknown origin" isn't the fix

It's a tempting rule, and some plugins offer it. It has two problems. It turns away real shoppers whose browsers sent no origin: people with ad blockers, people who said no to marketing cookies, and everyone on a checkout that doesn't send it. And it's easy to get round. The origin is a few fields the browser sends with the order, so a bot that fills them in gets through.

What a bot can't fake is the result: its cards keep getting declined. So what works is counting failed payments, per connection, per email address and across the whole store, and, during an attack, only taking orders from shoppers who actually opened your checkout page. A CAPTCHA that only sits on the checkout page has the same gap as the origin: bots that skip the page never see it. The card testing guide explains why.

Get warned for free

The free Ropeline plugin counts your failed orders for you. When 10 or more payments fail within 24 hours, it warns you on its Overview and in the WordPress Dashboard, with what to do next. It also guards your login against password guessing. Stopping the attack itself is part of Ropeline Pro.

And the free store check shows in 10 seconds whether your checkout takes orders straight from scripts, the way card-testing bots send them.

How Ropeline Pro stops it, automatically

Ropeline Pro counts the same orders WooCommerce marks as failed, and steps in on its own:

• 5 failed payments from one connection or one email address in an hour: that shopper's checkout pauses for an hour.
• 10 failed payments across your store in an hour: attack mode for 2 hours. Only shoppers who opened your real checkout page can pay, so bots that send orders straight to checkout are turned away, whatever origin they send. You get an email when it starts.
• Attack mode works from the first attack, even during Ropeline's first-week learning mode.
• Logged-in customers who have paid before skip attack mode, and verified AI shopping agents go straight through.
• Works with the classic checkout, the checkout block and pay-for-order pages, and with Stripe, PayPal and other gateways that mark a declined payment as failed.

Questions

Do the failed orders cost me anything?

On many payment plans a declined card costs nothing, but some charge a fee for every try. The stolen cards that went through will turn into disputes, with a fee each. And lots of declines can hurt your standing with the card companies, which can lead to real customers being declined.

Do failed orders count toward my Ropeline plan's size?

No. Store plans are sized by paid orders (processing or completed) in the last 30 days, so a card tester's failed orders never count.

Will Ropeline Pro block my real customers?

It's built not to. A pause only follows repeated declines from the same connection or email. During attack mode, shoppers who go through your checkout page, as almost everyone does, can still pay. If your store's checkout runs on a separate front end (a headless store or an app), you can turn attack mode off.

I already run Wordfence. Shouldn't it stop this?

Wordfence's own support has said that taking orders is the e-commerce platform's job, not WordPress's. What that means for card testing, and what does stop it: Does Wordfence stop card testing?