Carding Attack Prevention: Stop Card-Testing Bots

How to prevent carding attacks

To prevent carding attacks, stop the bots before a card ever reaches your payment provider. Put bot detection on every form that can charge a card, verify the result on your server before the payment call, and limit how many attempts one session, IP address, account or card gets. Card checks such as CVV and 3-D Secure then catch part of what gets through, and your decline rate tells you when someone is testing.

The measures, in the order a payment attempt meets them:

1. Put bot detection on every form that can charge a card: checkout, guest checkout, the payment method page in the customer account, donation and subscription forms. An invisible CAPTCHA does this without adding a step for customers.
2. Verify the CAPTCHA token on your server and create the payment only after it passes. A bot that skips the page and posts straight to your payment endpoint then gets nothing back.
3. Rate limit per session, account, email address and card, and per IP address as well. Carding bots rotate IP addresses, so an IP limit on its own slows them down less than you would hope.
4. Keep the card checks at your payment provider switched on: CVV, 3-D Secure and, where your provider supports it, address verification (AVS). They make a stolen card harder to use, but they run after the card has been submitted, so they cut losses without cutting the number of attempts.
5. Watch your decline rate and set an alert on it. A sudden rise in declined payments is the most reliable early sign of card testing.

Good carding prevention does most of its work in the first three steps, on your own server. Everything after that happens at or after the payment provider, when the attempt has already cost you.

What is a carding attack?

A carding attack is a form of credit card fraud in which bots test stolen card details on someone else’s website. The attacker does not want your products. They want to know which numbers on their list still work, and your checkout answers that question at your expense.

Carding and card testing are used almost interchangeably. Strictly speaking, carding is the whole business of trading and using stolen cards, and card testing is the step where the cards get checked. When a shop says it was hit by a carding attack, it nearly always means card testing: a burst of small payment attempts in a short time, almost all of them from bots.

Card testing costs you money even when no order ships. Depending on your payment provider, you may pay a fee for every authorization attempt. Test charges that go through turn into disputes and chargebacks once the cardholders spot them. A decline rate that jumps overnight is exactly what payment providers watch for, and it can lead to a review of your merchant account. And someone on your team has to find the fake orders, cancel them and refund them.

Card testing is one of several attacks on online shops. Our guide to e-commerce fraud prevention covers account takeover, gift card fraud and the rest.

How a carding attack runs

Most card testing follows the same five steps:

1. The attacker gets a list of card numbers from data breaches, phishing pages, malware or card skimmers, usually bought on criminal marketplaces. The CVV or the expiry date is often missing.
2. A bot picks a target: a shop or donation form that runs a card authorization and has little protection. Low order values and guest checkout make the job easier.
3. The bot submits one card after another, from many IP addresses and fresh sessions, so the attempts look like different customers. Missing digits are found by trying combinations, the same guessing game that brute force protection stops on a login form.
4. Your payment provider answers each attempt with approved or declined. Approved means the card works; declined means the bot moves on to the next one.
5. The working cards are sold as “verified” or used for bigger purchases elsewhere, often goods and gift cards that are easy to resell.

Some bots create customer accounts first, because a shop may allow saved cards or a faster checkout only after login. That is where carding meets fake account creation, and why the signup form deserves the same protection as the checkout.

How to stop bots testing stolen cards

To stop bots testing stolen cards, make every payment attempt pass a bot check that your server verifies before it talks to the payment provider. A proof-of-work makes each attempt cost computing time, and a bot score flags the sessions that behave like scripts. Combined with limits per card and per session, testing a long list of cards stops being worth it.

Protect every form that can charge a card

Card testers go for the easiest form that triggers an authorization, and that is not always the checkout. Check the payment method page in the customer account, donation forms and free trials that verify a card as well. Protect the API endpoint behind each form too, not only the page.

Verify the token before the payment call

A CAPTCHA that only runs in the browser does nothing against a script that posts directly to your payment endpoint. Your backend has to verify the token, and it should create the payment only after the check passes. Skip this step and the bot check protects nothing.

What changes with AI-driven bots

Many carding bots now run real browsers, type at human speed and pass simple checks such as hidden form fields. AI agents make that easier still. That shifts the weight from spotting bots to making attempts expensive: if every payment attempt needs a solved proof-of-work, and the work grows with the risk of the request, a bot that tries thousands of cards pays for every one of them, however human it looks.

Signs of a carding attack

Card testing rarely hides for long if you know where to look:

• A sudden rise in declined payments, often at night or on a weekend
• Many small orders or card checks within a few minutes
• The same card number tried with different expiry dates or CVV codes
• Many different cards from one session, device or IP range
• Guest orders with random names, odd email addresses or billing addresses that do not match the card’s country

One of these on its own can be a bad day. Two or three at once usually means a bot is testing cards on your checkout.

What to do during a carding attack

If an attack is running right now:

1. Raise the bot protection on the payment forms. With TrustCaptcha you can make the proof-of-work harder for the traffic the attack comes from, for example by country or IP range.
2. Tighten the rate limits per card, session and account, and block the IP ranges the attack uses.
3. Show customers a generic error when a payment fails, so a bot cannot tell a wrong CVV from a blocked card.
4. Turn off guest checkout for a while if the attack keeps going.
5. Tell your payment provider. They see the pattern across many merchants and can adjust their own fraud rules.
6. Cancel and refund the test charges that went through, before the cardholders file disputes.

How TrustCaptcha protects the checkout

TrustCaptcha sits on the payment form and starts on its own while the customer fills it in. The browser solves a proof-of-work in the background, and the widget sends signals for a bot score, where 0 means human. The more suspicious the request, the harder the proof-of-work. A customer sees no puzzle. A bot that wants to test a few thousand cards pays for each attempt with computing time.

Your server receives a token with the form, checks it with one REST call and gets the result back, including the bot score. Only then does it create the payment. Where you draw the line is up to you: block, allow, or send borderline requests through an extra check, such as 3-D Secure if your payment provider lets you request it.

Dynamic proof-of-work is part of every plan. Bot detection with risk scoring, custom proof-of-work rules and IP allow and block lists start with the Solo plan, and geoblocking and custom access rules with Team.

For WooCommerce, the WordPress CAPTCHA plugin protects the checkout, login and registration. The Shopware CAPTCHA plugin covers the checkout and customer registration, and for a custom shop you add the widget and the server check yourself.

TrustCaptcha sets no cookies, processes data in EU data centers and comes with a Data Processing Agreement for every customer: the profile of a GDPR-compliant CAPTCHA that European shops look for.

Try TrustCaptcha

Every plan starts with a 14-day free trial, and non-commercial websites can use TrustCaptcha for free. Start your free trial and put it on your checkout first, where card testing costs you the most.