If your WooCommerce or Magento store is under a carding attack, you need to stop the abusive checkout traffic at the edge, make sure CAPTCHA failures block rather than approve payments, and add fraud controls at the payment gateway.
That is the short answer.
The longer answer is that we just dealt with one of these attacks, and it was considerably more complicated than “install a CAPTCHA plugin and turn on Cloudflare.” We had those things. The bots were still testing cards.
There was a CAPTCHA on checkout. It was working.
Except when it wasn’t.
What is a WooCommerce carding attack?
A carding attack, also called card testing, is when an attacker uses your checkout to test a large batch of stolen credit card numbers. They make lots of small payment attempts and study the responses from the payment gateway.
A declined payment tells them one thing. A failed CVV tells them something else. An approved transaction tells them they found a usable card.
Your store is basically being used as a free stolen-credit-card testing machine, which is not a service most of us remember agreeing to provide.
If you have ever been on the business end of a carding attack on a WooCommerce store, you know that the stress-o-meter climbs quickly.
On one side, you have an increasingly annoyed payment processor sending vaguely ominous messages about fraud, chargebacks and possibly enormous fees if you don’t get the problem under control. On the other, you have a web developer telling you that Google reCAPTCHA or Turnstile is already installed and working. Everyone agrees the store is protected. The stolen cards sailing through checkout apparently did not get that memo.
Meanwhile, failed and cancelled orders are piling up. The customer names keep changing, but they are buying the same inexpensive product or following the same strange billing pattern. Your gateway is recording declined cards as fast as it can process them, the server CPU is climbing, PHP workers are disappearing and checkout is getting slower for the people who are actually trying to give you money.
Then your developer comes back with the next bit of bad news: this is not one attacker at one address. The requests are arriving from hundreds of different places, including commercial hosting companies and networks of ordinary-looking residential connections. “Can’t we just block them?” is the obvious question. Unfortunately, blocking them one at a time feels a little like standing in the rain with a flyswatter.
The obvious temptation is to turn every fraud control up to eleven. Block countries. Block networks. Challenge everyone. Require customers to identify three traffic lights and a motorcycle before they can buy a $14 candle.
But you don’t want to stop the attack by making checkout unusable for legitimate customers. That is technically one way to achieve zero fraudulent orders, of course. It also achieves zero other orders.
This is the uncomfortable part of a carding attack: you are trying to shut the door quickly without slamming it on the actual customers standing in the doorway.
This can happen on any ecommerce platform. We see it often on WooCommerce stores, but Magento, Shopify applications, donation platforms and custom payment forms can all be targeted.
Our attack looked like a CAPTCHA bypass
At first, this looked pretty simple: attackers had figured out how to bypass the Turnstile protection on WooCommerce checkout.
That would not have been especially surprising. We have already written about why Google reCAPTCHA by itself is no longer reliable protection against WooCommerce carding. Modern bots can use real browsers, rotate IP addresses, preserve cookies and behave just enough like a person to get past a basic challenge.
But this case was different.
We checked the checkout form. Turnstile was there. We tested it manually. It rejected missing or invalid tokens. Cloudflare was active. The payment gateway was correctly declining most of the cards.
And yet the attack kept going.
We went through Cloudflare events, web server access logs, PHP logs, WooCommerce orders, plugin settings and payment gateway responses. Then we went through them again, because apparently we enjoy suffering.
The logs, of course, did not put up a helpful little sign saying HERE IS THE PROBLEM.
It took awhile to find the (damnably frustrating) root cause.
The attackers were turning the CAPTCHA failsafe against the store
Every legitimate Turnstile submission has to be verified on the server. The shopper’s browser receives a token, then WooCommerce sends that token to the backend. Your server contacts Cloudflare’s Siteverify service to confirm that the token is valid.
Cloudflare requires this server-side verification. Simply displaying the Turnstile widget on the checkout page is not enough.
During the carding attack, the bots hammered the WooCommerce checkout endpoint with a huge number of simultaneous requests. In a classic WooCommerce checkout, this commonly includes /checkout/ and ?wc-ajax=checkout. WooCommerce Blocks and headless stores may instead receive the attack through the Store API, including endpoints such as /wp-json/wc/store/v1/checkout.
Each request that reached WordPress created more PHP work and, in this case, more outbound verification traffic. Eventually some of those Turnstile verification requests began failing or timing out.
This is where things gets weird.
The Turnstile plugin had its failsafe enabled. The idea behind that setting is fairly reasonable: if Cloudflare becomes temporarily unreachable, do not prevent a real customer from submitting the form.
The setting sounded harmless, it was not.
When the plugin could not complete the verification request, it treated the failure as permission to continue. Instead of saying, “I cannot verify this customer, so I am stopping checkout,” it effectively said, “Cloudflare seems unavailable, so this is probably fine.”
It was not fine.
The attackers did not necessarily solve the CAPTCHA. They generated enough checkout traffic to make verification unreliable, then the plugin’s own fail-open behavior passed their requests to the payment gateway.
The lock was not picked. The burglar leaned on the doorbell until we unplugged the lock ourselves.
Why this was so difficult to diagnose
Ordinary testing told us Turnstile was working. One developer completing one checkout did not reproduce the concurrency and timeouts created by the attack. Cloudflare was not necessarily “down,” either. The public site and Turnstile widget could appear perfectly normal while the verification request between WordPress and Cloudflare was failing.
The payment gateway was also doing its job. Most of the stolen cards were declined. But those declines proved the bots had already made it through WooCommerce and reached the gateway, so this was not exactly comforting news.
What looked like one problem was really two. It was a fraud attack, but the request volume was also creating an application-layer resource exhaustion problem. And the security plugin was helping the attacker whenever that second problem got bad enough.
That is not usually the first place anyone looks.
More server capacity might have delayed the failure. It would not have corrected the underlying logic. Adding PHP workers, RAM or CPU can help keep a store alive during traffic surges, but it is not a substitute for stopping abusive payment attempts. Otherwise you have simply purchased the attacker a larger card-testing machine.
Step 1: Make CAPTCHA verification fail closed
For an ordinary contact form, allowing a submission during a CAPTCHA outage may be a tolerable tradeoff.
For a payment form? No.
If a checkout request cannot be verified, it should not reach the payment gateway. The customer may have to try again, which is annoying. Thousands of fraudulent authorizations and a frozen merchant account is more annoying.
On the version of Simple CAPTCHA with Cloudflare Turnstile we examined, the failsafe choices were essentially to allow the submission or use reCAPTCHA as a backup. There was not a supported block value.
In fact, entering an unsupported value could still fall through to the plugin’s allow behavior. Do not assume that this command will protect you:
wp option update cfturnstile_failsafe_type "block" --allow-rootFor the configuration we dealt with, the correct fail-closed approach was to disable the failover feature entirely:
# Inspect the current settings
wp option get cfturnstile_failover --allow-root
wp option get cfturnstile_failsafe_type --allow-root
# Disable failover so a verification error does not become an automatic pass
wp option delete cfturnstile_failover --allow-rootYou can also disable Failsafe Mode in the plugin settings.
Plugin behavior changes between versions, so confirm this on your installed version and test it. Submit a checkout without a token, with an invalid token and while outbound verification is intentionally unavailable. All three should stop before payment authorization.
If you are not running WP-CLI as root, leave off --allow-root.
Step 2: Protect the actual payment endpoint in Cloudflare
A challenge on the visible checkout page is useful, but the payment endpoint is what matters. Bots may skip the page entirely and submit directly to WooCommerce, the Store API, Magento REST or GraphQL.
Use Cloudflare WAF and rate limiting to identify repeated POST requests to checkout and payment endpoints. Do not blindly rate-limit every visit to /checkout/. Real customers refresh pages, correct addresses and retry legitimate cards.
For WooCommerce, pay particular attention to ?wc-ajax=checkout, /wp-json/wc/store/v1/checkout and any custom payment, saved-card or add-payment-method endpoint used by your gateway.
A starting limit of roughly three to five payment submissions per minute per IP or session may be reasonable for many stores, but it is not a universal number. A corporate office, school or mobile carrier may put many real shoppers behind one public IP.
Start with logging if possible. Review what would have matched, then challenge or block. Cloudflare’s rate-limiting rules can protect specific endpoints before the traffic reaches PHP.
We generally prefer a managed challenge before a broad block, particularly for hosting-provider networks. Some carders attack from AWS, DigitalOcean, Hetzner and similar infrastructure. Others use residential proxies, so blocking every cloud provider is not a complete strategy and can create some entertaining support tickets.
For more background, see our guides to using Cloudflare with WordPress and Cloudflare protection for Magento 2.
Step 3: Add protection at the payment gateway
Cloudflare protects your server. Your payment gateway should independently protect the card network.
At a minimum, require CVV when the gateway supports it, use Address Verification Service checks and decide what should happen when either one fails. The gateway should also notice repeated attempts involving the same card, email address, device or session, even when the attacker keeps changing IP addresses.
This is usually described as payment velocity: how many times the same card, customer or device is allowed to attempt a transaction within a certain period. Stripe Radar, Braintree fraud tools, WooPayments and other gateways each implement it differently. The important part is that your store should not rely on one IP address or one CAPTCHA to decide whether a payment attempt is legitimate.
Set up alerts for sudden increases in authorization failures, too. Finding out about a carding attack from a threatening message sent by your payment processor is not really the monitoring system we would choose.
If the attack is active and severe, temporarily disabling saved-card additions, guest checkout or the affected payment method may buy time. That is triage, not the long-term fix.
Step 4: Do not forget WooCommerce APIs and Magento
We are describing a WooCommerce incident, but the same architecture applies to Magento and other ecommerce systems.
Magento carders may target REST endpoints for guest-cart payment submission, customer-cart payment submission or GraphQL checkout mutations. Protecting the HTML checkout page does very little if an attacker can send payment data directly to an API.
On a Magento store, we would compare REST and GraphQL request volume against guest cart creation, payment-information submissions, unfinished quotes and gateway authorization failures. A sudden river of quotes that never become real orders is usually trying to tell you something.
GraphQL makes this especially tricky because many different operations use the same URL. Path-based rate limiting alone may not distinguish ordinary product browsing from a payment submission. Application logging and gateway velocity controls become even more important.
Magento security and maintenance is not really optional when a store is processing live payments. Our Magento Maintenance and Security Plan goes into the ongoing patching, log review and performance work required to keep these systems stable.
Step 5: Layer the defenses
Honeypots, CAPTCHA, Cloudflare challenges and WordPress security plugins can all help. None of them should be the only thing standing between a bot and your payment processor.
The durable version of carding protection has several layers. CAPTCHA tokens are validated on the real payment endpoint. A failed verification blocks the transaction. Cloudflare rate-limits abusive traffic before it can consume all of the server’s resources. WooCommerce or Magento limits repeated checkout attempts, and the gateway separately watches for suspicious payment velocity, CVV failures and AVS mismatches.
Those layers also need to leave useful logs behind. During an attack, we want to connect the Cloudflare request to the application request and then to the gateway result. Otherwise every system gives you a small, confident and mostly useless piece of the story.
And test it.
Not just one happy-path checkout from your laptop. Test missing tokens, invalid tokens, direct API requests, gateway failures and unavailable verification services. Security systems tend to be very confident right up until two of them interact in a way nobody expected.
The real lesson from this carding attack
Our first instinct was that the attackers had bypassed Turnstile. That was only partly true.
They had found a path around it, but the path depended on traffic volume, server behavior, outbound API verification, plugin failover logic and the payment gateway all interacting at once.
That is why this took so much work to find. No individual system looked completely broken. Together, they created a very effective bypass.
So yes, install CAPTCHA. Use Cloudflare. Enable fraud protection. Keep WooCommerce and Magento updated.
But also follow the request all the way through.
Browser. CDN. Web server. PHP. Plugin. Ecommerce platform. Gateway.
Somewhere in that chain may be a friendly little failsafe holding the door open for several thousand stolen credit cards.
If your store is suddenly collecting failed orders, gateway warnings or checkout traffic that makes no sense, our team provides managed WordPress and WooCommerce maintenance, Magento support and incident investigation. You can also send us the site and a short description of what you are seeing.
We have, unfortunately, become pretty good at finding this stuff.
