Card Testing Attacks: Warning Signs, Costs and How to Stop Them

Last updated: November 2, 2026

It’s 2:40 a.m. and an animal rescue’s donation form, which normally takes about 30 gifts a day, has just processed 1,100 attempts in an hour. Almost all were declined. The 60 that went through were $1 donations from cards in a dozen countries. Nobody on staff notices until the morning, when the gateway bill and the first fraud alerts arrive together.

That’s a card testing attack. Criminals with lists of stolen card numbers use your checkout to find out which cards still work. They don’t want your product. They want a quick “approved” so they can sell or use the card somewhere else.

Card testing attacks hit small merchants as hard as large ones, often harder, because small sites tend to have fewer controls. This guide covers how to spot an attack early, what it really costs (including how it shows up in Visa’s monitoring), the controls that stop it, and a step-by-step incident response plan. We’ll also note where Midcove helps and where you’ll rely on your gateway or your own site.

Card testing attacks are automated attempts to validate stolen card numbers by running many small or zero-dollar authorizations through a merchant’s checkout. Fraudsters use the approvals to confirm which cards are live. The merchant pays gateway fees, absorbs disputes, and risks network monitoring, even though no goods are sold.

How Card Testing Attacks Work

Stolen card data is cheap and often stale. A batch bought on a fraud forum may contain thousands of numbers, many already cancelled. Before using or reselling them, criminals need to know which still work.

So they look for a checkout that will run an authorization with minimal friction. Donation forms, free-trial signups with a $1 auth, low-priced digital goods, and exposed payment APIs are favorite targets. A bot then fires card after card through the form, often rotating IP addresses, names, and emails to look like different people.

Two common patterns

• Validation testing: full card numbers from a breach are run one by one to see which are live.
• Enumeration: the attacker has a partial number or a BIN and guesses the remaining digits, expiry dates, or security codes. This produces huge volumes of declines with very few approvals.

Either way, your merchant account does the work and carries the risk.

Warning Signs of Card Testing

Stripe’s guidance on card testing notes that most attacks show up as a sharp rise in failed authorizations. That’s the headline sign, but there are others worth watching.

• Decline spike: your decline rate jumps from its normal range to 70%, 80%, or higher within an hour.
• Tiny amounts: a burst of $0.50, $1, or minimum-price transactions, or the same small amount repeated.
• Odd hours: volume surges when your real customers are asleep.
• Mismatched data: billing names that don’t match emails, random-looking email addresses, AVS and CVV failures across the board.
• Many cards, few identities: one IP, device, or email trying many different cards.
• Sequential numbers: card numbers sharing a BIN and differing only in the last few digits.
• Decline code mix: lots of “invalid card number,” “incorrect CVV,” or “expired card” responses rather than “insufficient funds.”

Watch your reports for the shape: a wall of declines followed by a thin trickle of small approvals. That trickle is what the attacker came for.

Why small merchants spot it late

Most small teams don’t watch the gateway console at night, and many gateways alert on approvals or disputes rather than on declines. If your only signal is the monthly statement, an attack can run for days. A payment reporting view that shows hourly decline rates per MID makes the spike obvious.

What Card Testing Really Costs

Merchants often shrug off card testing because “the cards were declined anyway.” The costs are real, and some arrive weeks later.

Per-attempt fees

Many gateway plans charge a per-transaction fee whether the authorization is approved or declined. At even ten cents an attempt, 50,000 test attempts is a $5,000 bill for zero revenue. Check your own gateway and processor fee schedule; some also charge processor authorization fees on declines.

Disputes from approved test charges

The cards that pass belong to real people. When they spot a strange $1 charge from a merchant they’ve never heard of, many call their bank. Each fraud dispute adds a chargeback fee and counts against your dispute ratios.

Network monitoring

Card networks treat enumeration as a merchant problem, not just an issuer problem. Visa’s Acquirer Monitoring Program (VAMP) tracks enumeration separately from fraud and disputes. Industry summaries of the program describe an enumeration threshold that pairs a 20% enumeration ratio (enumerated authorizations as a share of total authorizations) with a minimum of 300,000 enumerated transactions in a month. Check the current figures with your acquirer, and see our Visa VAMP explainer for how the program works. The official starting point is Visa’s published rules.

Acquirer and gateway action

Even below network thresholds, your acquirer sees the decline spike. Repeated attacks can lead to reserve requests, rate reviews, or a closed account. For high-risk merchants who fought hard to get a MID, that’s the most expensive outcome of all.

Staff time

Someone has to investigate, refund the approved test charges, answer bank inquiries, and fight or accept disputes. A two-hour attack can mean two days of cleanup.

How to Stop Card Testing Attacks

No single control stops every attack. Stripe’s own prevention guidance makes the same point: one heuristic, like blocking IPs, isn’t enough on its own. Layer several controls so that a bot hitting one wall runs into the next.

1. Velocity limits and lockouts

Limit how many attempts a single IP, email, device, or card can make in a set window. After a few failures, lock that source out for a period. A 24-hour lockout after repeated failed attempts is a simple, strong default: honest customers rarely fail five times in a row, and bots can’t wait a day per IP.

2. CAPTCHA and bot checks

Put a bot challenge in front of the payment step, especially on donation forms and trial signups. Invisible or risk-based CAPTCHAs add little friction for real users. This control lives on your website, not in your gateway.

3. Minimum transaction amounts

If your smallest real order is $20, there’s no reason to accept $1 authorizations. Raising the minimum on donation forms (say, to $5) removes much of the appeal for testers. Pair it with a rule that flags repeated identical small amounts.

4. Require AVS and CVV

Require the security code and a billing ZIP or postal code on every card-not-present payment, and decline on CVV mismatches. Enumeration attacks that guess codes produce long runs of CVV failures, which are easy to catch.

5. Targeted BIN blocks

When an attack uses cards from one or two BINs, a temporary block on those BINs can stop it cold. Remove the block once the attack ends, because those BINs also cover honest cardholders. Our guide to IP, email, and BIN fraud filters covers how to weigh that trade-off.

6. Protect your endpoints and keys

Testers don’t always use your checkout page. Sometimes they call your payment API directly, or reuse a public key exposed in your site’s code. Make sure payment requests come from your own server with proper authentication, and rotate keys if you suspect a leak.

7. 3-D Secure for risky traffic

Sending suspicious attempts through 3-D Secure adds an issuer check that bots usually can’t pass. It adds friction, so many merchants trigger it only for higher-risk attempts.

Midcove’s fraud prevention layer covers the merchant-side pieces of this list: IP, email, phone, and BIN block lists plus an automatic 24-hour lockout after repeated failed attempts, applied across every connected gateway. Custom velocity limits are available on Enterprise. CAPTCHA, minimum amounts on your site, and 3-D Secure stay with your website and gateway.

Controls Compared

Incident Response: The First 24 Hours

When an attack is live, speed matters more than perfection. Here’s a sequence that works for most merchants.

1. Confirm it’s an attack. Check the decline rate, transaction amounts, and the spread of IPs and cards over the last few hours. A real sale rush doesn’t look like 90% declines.
2. Slow the bleeding. Turn on or tighten lockouts, enable CAPTCHA, and raise the minimum amount. If the attack is heavy, take the targeted form offline for an hour. Lost donations for an hour cost less than 20,000 more attempts.
3. Block the obvious sources. Add the top attacking IPs, emails, and any concentrated BINs to your block lists, with a short expiry.
4. Refund approved test charges. Find the small approvals that came from the attack and refund them right away. A refunded charge is far less likely to become a dispute. A refund management tool that can work through a list across MIDs speeds this up.
5. Tell your gateway and acquirer. Report the attack, the window, and the steps you’ve taken. They may block traffic upstream and will note that you responded quickly.
6. Check for a technical hole. Look for exposed API keys, an unprotected endpoint, or a test form left live. Rotate credentials if there’s any doubt.
7. Watch for 48–72 hours. Attackers often return from new IPs once the first wave is blocked. Keep alerts tight until volume is normal.

After the Attack

Once things are quiet, do a short review while details are fresh. What tipped you off, and how long did it take? Which control did the most work? What would have caught it an hour earlier?

Then make the useful changes permanent. Keep the lockout and minimum amount. Remove temporary BIN blocks. Set an alert on hourly decline rate so the next attack wakes someone up instead of running all night.

Finally, track the aftermath. Fraud disputes from approved test charges can arrive weeks later. Keep an eye on your ratios per MID; our guide to chargeback ratio monitoring explains what to watch and when to worry.

Key Takeaways

• Card testing attacks use your checkout to validate stolen cards; the giveaway is a sudden wall of declines followed by small approvals.
• Costs include per-attempt fees, fraud disputes, network monitoring for enumeration, and possible action from your acquirer.
• Layer controls: velocity lockouts, CAPTCHA, minimum amounts, required CVV and AVS, targeted BIN blocks, and protected API endpoints.
• During an attack, slow it first, block sources second, then refund approved test charges quickly to prevent disputes.
• Remove temporary BIN blocks afterward, but keep lockouts and decline-rate alerts permanently.
• Donation forms, trial signups, and low-priced digital products are the most common targets.

Frequently Asked Questions

What is a card testing attack?

A card testing attack is when fraudsters use a merchant’s checkout or payment API to check whether stolen card numbers still work. Bots run many small or zero-dollar authorizations, and each approval tells the attacker a card is live. The merchant pays the fees and handles the disputes, while the stolen cards are used elsewhere.

How do I know if my site is being card tested?

The clearest sign is a sudden jump in declined transactions, often at night, with many different cards and very small amounts. Other signs include random-looking emails, failed CVV and AVS checks, many cards from one IP, and card numbers that share the same first digits.

Why do fraudsters target donation pages?

Donation forms often accept any amount, including $1, ask for little information, and rarely use bot checks. That makes them an easy place to run cheap test authorizations. Setting a minimum gift, adding CAPTCHA, and locking out repeated failures removes most of the appeal.

Do I have to pay fees on declined card testing attempts?

Often, yes. Many gateway plans charge a per-transaction fee on every authorization attempt, approved or declined, and some processors charge authorization fees too. Check your fee schedule. Some gateways will review fees from a documented attack, so report it promptly and keep records.

Should I refund card testing transactions?

Yes. Refund approved test charges as soon as you identify them. The real cardholder didn’t make the purchase, and a refund made before they contact their bank usually prevents a fraud chargeback. Refunds also show your acquirer that you responded quickly.

Does card testing affect my chargeback ratio?

It can. Approved test charges often turn into fraud disputes when cardholders notice them, and those disputes count toward your ratios. Visa’s monitoring program also tracks enumeration activity on its own, so a large attack can draw attention even before disputes arrive.

Will CAPTCHA stop card testing?

CAPTCHA stops many automated attacks, but not all. Some attackers use CAPTCHA-solving services, and others skip your page and call the payment API directly. Use CAPTCHA as one layer alongside velocity lockouts, minimum amounts, required CVV, and protected endpoints.

What is the difference between card testing and enumeration?

Card testing usually means checking full stolen card numbers to see which are valid. Enumeration means guessing missing parts of card data, such as the last digits, expiry date, or CVV, by trying many combinations. Enumeration creates far more declines per approval, which is why card networks monitor it specifically.

How long do card testing attacks last?

Some last minutes, others run for days if nobody notices. Attackers often pause and return from new IPs after the first wave is blocked. Keep tighter controls and alerts in place for at least two to three days after an attack appears to end.

Staying Off the Tester’s List

Card testing attacks look for the easiest checkout on the internet. You don’t need perfect defenses; you need to be harder to use than the next site. Lockouts, a sensible minimum amount, required CVV, CAPTCHA, and protected endpoints remove most of the easy wins. Alerts on hourly decline rates turn an all-night attack into a one-hour one.

If you run several merchant accounts, the same attacker can move from one checkout to the next. Midcove applies one set of block lists and a 24-hour failed-attempt lockout across NMI, Authorize.Net, Stripe, and PayPal, and its dashboards show declines per MID in one place, so you see the spike before the bill arrives.