The first hour of a card-testing attack, in order

The order list fills with failed orders, a few dollars each, all guests, all different names. Your gateway sends a warning email. You have a card-testing attack, and the next hour decides how much it costs you.

Panic makes people do things in the wrong order. They delete orders, switch off the gateway, and install three plugins at once. Here is the order we work in when a store is under attack right now.

Minute 0 to 5: confirm it is an attack

Card testing has a shape. A script tries stolen card numbers against your checkout to learn which ones still work. So you see many orders in a short window, small totals, guest checkouts, and a high share of failed or declined payments.

Look for these signs in the order list:

• Failed or pending orders arriving minutes or seconds apart.
• The same cheap product, or the cheapest shipping option, again and again.
• Billing names and emails that change on every order, often random or nonsense.
• Card numbers in the gateway dashboard that share the same first six digits.

If you see that pattern, stop investigating and start acting. You can study the details later.

Minute 5 to 15: slow the bleeding

Your first goal is fewer attempts per minute. Every attempt can cost a gateway fee, and a high decline rate is what makes a gateway review or pause your account.

1. Open your gateway dashboard and turn on its own fraud rules if you have them. Stripe Radar, for example, lets you block payments with a high risk level. These rules act before WooCommerce even sees the result.
2. If you run more than one gateway, check which one the bot is using. Disable that one only if you have a second gateway your real customers can use.
3. Put a bot check on checkout. A score-based check such as reCAPTCHA v3 adds no puzzle for real customers, so you can switch it on in the middle of a busy day.
4. Turn on a rate limit for checkout. WooCommerce has one for the Store API, but it is off by default, and it does not cover the classic checkout.

Do not switch off checkout entirely unless the attack is very fast and nothing else works. Real customers are still trying to buy.

Minute 15 to 30: close the other doors

Bots rarely use the checkout page you see. They post straight to the endpoint behind it. So a fix that only touches the visible page can leave the real target open.

Check every route that can take a card on your store:

• The classic checkout endpoint, which the shortcode checkout posts to.
• The Store API checkout route, which the Checkout block uses, and which exists on most stores even if you never used the block.
• The pay-for-order page, where a failed order can be paid again.
• The add payment method page in My Account, which can test a card with no order at all.

When an attack slows down on one route and keeps going, it usually moved to another one. Watch the gateway dashboard, not just the order list, because the add payment method route leaves no order behind.

Minute 30 to 45: keep the evidence

Do not delete the junk orders yet. Each order holds the IP address, the user agent, the gateway transaction ID, and order notes from the gateway. You need those to report the attack, to dispute fees, and to tune your rules.

Instead, filter the order list to the attack window and export what you need. If your logs only started recording after the attack began, accept that. Logs cannot fill in events that happened before they existed.

If any test payment succeeded, refund it. A successful charge on a stolen card turns into a chargeback later, and chargebacks cost more than a refund.

Minute 45 to 60: talk to your gateway

Write to your gateway support with the time window, the number of attempts, and what you changed. Gateways see card testing every day. A merchant who reports it early and shows the steps they took is in a much better position than one who stays silent until the gateway notices.

Ask them two direct questions. Will they reverse or waive fees for the failed attempts? And did they flag or restrict the account?

After the first hour

Once the attack slows, go back and fix things properly. Review your rate limit numbers against real customer behavior. Decide whether guests really need to create orders without any check. Look for stray checkout pages left over from a theme demo or a staging copy.

Expect the attack to come back. Scripts often return a day or a week later to see if the door is open again. The fixes you put in a hurry should become the fixes you keep.

Where Checkout Bouncer fits

We built Checkout Bouncer for the middle part of this hour. It puts reCAPTCHA v3 on the classic checkout, the Checkout block, pay-for-order, and add payment method, adds an order-rate throttle that works with any gateway, and logs what it blocked. It is free on WordPress.org, and it fails open if Google is down, so real customers can still pay.