Card testing attacks: how they work and how to stop them

A card testing attack rarely looks like fraud at first. It looks like a bad hour: declines climb, a run of tiny orders appears, and the support inbox stays quiet because none of these customers are real. Someone has pointed a script at your checkout and is using it to find out which stolen card numbers still work.

This article explains how card testing works, the signs in your data, why declined attempts still hurt, which controls stop it and what to do while an attack is running. For how Visa counts all this in its monitoring programme, read our guide to VAMP; this article stays on the attack itself.

What is a card testing attack?

Card testing is automated checking of card details against a live payment form. Visa’s rules call it an Enumeration Attack, defined as the systematic or routine submission of card-absent transactions to fraudulently obtain or validate payment information. Stripe lists the other common names: carding, account testing, enumeration and card checking.

Visa describes the method in its June 2026 merchant guide. Fraudsters test or guess card numbers, expiry dates, CVV2 values and postal codes to find credentials that are valid. Those credentials are then used for fraud or sold on, and Visa calls enumeration a leading indicator of fraud to come. It says the practice causes over a billion dollars in fraud losses a year across the payments ecosystem.

The attacker has no interest in your goods. Your checkout is a free tool for reading issuer responses.

How does card testing work?

Stripe says testers run scripts that push large numbers of card details through at once and collect the 3-D Secure or issuer responses to see which cards are valid. They use two routes:

• Card setup. Saving a card triggers a validation. Stripe says this is the route testers prefer, because validations during setup don’t typically show up on cardholder statements, so the cardholder is less likely to notice.
• Small payments. Low amounts are less likely to be noticed and reported. Visa says attack transactions are often less than USD 10.

Visa says the most common approach is to target legitimate merchants with weak fraud controls. Stripe says sites with free-text amount fields, such as donation and pay-what-you-like pages, are frequent targets, and that guest checkout makes a payment form easier to reach. A leaked API key is a further route: Stripe warns that testers with your credentials can create payments directly, and Visa advises rolling API keys if attacks are hitting your API rather than your website form.

What are the signs in your payment data?

Stripe says you can identify most card testing by a significant increase in failed authorisations and payments. The table combines the symptoms Stripe lists with the alerts Visa recommends. None of these is proof alone, so look for several together.

Signal	Where to look	Source
Spike in failed or blocked payments	Hourly approval rate, blocked count	Stripe
Low amounts, nonsense customer names and emails	Payment list, sorted by amount	Stripe
Large volume of approvals or declines from a similar BIN range	Declines grouped by BIN	Visa
Rise in reversals soon after approval	Reversal count	Visa
One device or email using many different cards	Attempts grouped by device and email	Visa
Mismatch between IP location, time zone and browser language	Risk review queue	Visa
Bursts of generic declines, CVV failures, do not honor and suspected fraud codes	Decline codes by BIN range	Stripe, Visa

Set alerts on these rather than waiting for a monthly report. Our article on building a decline dashboard covers the views and alert levels. Check one thing before you treat a spike as an attack: Stripe notes that excessive retries can look like card testing if they arrive in spikes with a low success rate, so rule out your own retry jobs first.

Why does it matter if the payments are declined?

Because most of the damage does not depend on approval. Stripe lists these consequences, and some build the longer an attack runs:

• Disputes. Some test payments succeed. Cardholders notice them and report fraud, which leads to fraud warnings and disputes.
• Higher decline rates. A large number of declines can damage your reputation with issuers and networks, making all your payments look riskier. Stripe says this can raise declines on legitimate payments even after the testing stops. That is where card testing feeds false declines.
• Fees. Authorisation fees and dispute fees add up. Visa adds that enumeration increases processing fees and system integrity fees for non-compliant authorisation attempts.
• Strain on your systems. The extra requests can overload your infrastructure and disrupt real customers.
• Bad data. Stripe warns that test payments can look like good new customers in your reporting.

At scheme level, Visa monitors enumeration separately from disputes. Stripe’s documentation says an account enters Excessive enumeration monitoring at 300,000 enumerated transactions and a 20% ratio of authorisations, that the count includes approved and declined attempts that reach the processor, and that Visa uses a machine learning model to identify them. Stripe also says Visa does not assess fines for enumeration monitoring. These figures may change, so check them with your acquirer. The fraud reports that follow are the larger risk, because they count towards the VAMP ratio, and the VAMP article explains how.

Visa’s guide also says all VisaNet clients are monitored for enumeration, and that Visa works with acquirers to remediate vulnerable merchants. In practice, your acquirer may call you before any threshold is reached.

What stops card testing?

A combination. Stripe says simple firewall rules or filters based on one signal, such as IP address, are usually not enough, because testers vary their technique. Stripe’s example of a combination: let the first attempt from an IP address through, then require CAPTCHA for further requests from that address over the next few hours.

Control	What it does	Watch out for
CAPTCHA or bot checks	Blocks automated scripts	Must be validated on the server, on every request that can validate a card or take a payment
Velocity limits	Caps attempts per card, IP, device, email and session	Shared IP addresses; see our guide to velocity rules
Limits on saving cards	Caps cards per account and session, and accounts per IP	Covers the setup route that payment rules can miss
Blocking	Stops known bad cards, IPs and BIN ranges	Testers rotate, so blocks age quickly
Login or session checks	Makes the payment form harder to reach	Adds a step for guest shoppers
CVV and address checks	Raises the cost of guessing	Stripe warns that strict rules can trip wallet payments, which usually carry no CVC
3-D Secure	Adds issuer authentication	Testers can still read the response
Minimum amount	Removes the cheapest test on free-text fields	Scheme rules apply; see below
Network tokens with domain controls	Limits misuse of tokens	Covers tokenised cards only

Visa’s guide gives a useful example of a CAPTCHA trigger, such as five authorisations from one IP address or card number in a set timeframe, and recommends limiting operations per user session. It also suggests device fingerprinting with proxy piercing to spot a botnet behind many addresses, and random pauses when checking an account to slow brute-force attempts. Fraud screening covers where these checks sit in the wider flow.

Do minimum amounts work?

They help where the customer types the amount. Visa’s guide tells sites with donation or free-text amounts to set a minimum as high as is appropriate for most donors, because small charges are less likely to attract attention.

Be careful outside that case. Visa’s Core Rules say a merchant must not set a minimum transaction amount as a condition for honouring a card. The exceptions include European Economic Area transactions, domestic transactions in the UK, and US-issued credit cards at US merchants, where the minimum cannot exceed USD 10. Check with your acquirer before you apply a minimum to card payments, especially in other regions.

What should you do during an attack?

Stripe’s checklist for an active attack is short: identify the activity, refund fraudulent payments, add mitigations, monitor the result and contact your provider if it continues. A fuller version:

1. Confirm it. Check for several signals from the table, and rule out your own retry job.
2. Slow it down. Turn on CAPTCHA or tighten it, and lower velocity limits for the affected route.
3. Close the route. Add limits to the save-card step, the payment step and any public API endpoint. Roll API keys if testers are calling your API directly.
4. Block what is clearly bad. Block the cards, IP addresses and BIN ranges involved. Visa suggests adding IP addresses with multiple failed card payments to a blacklist for manual review.
5. Stop retries. Stripe warns not to keep retrying cards saved on fraudulent customers after an attack, because that repeats the attack. Exclude these payments from cascades too.
6. Clean up what got through. Reverse uncaptured authorisations where you can. Stripe says issuers don’t have to report fraud on an authorisation reversed before capture, whereas a captured payment can be reported even if refunded. Refund captured fraudulent payments through the provider that took them.
7. Hold the goods. Cancel orders linked to the attack, so you don’t ship to testers.
8. Tell your acquirer. They may already have seen it. Stripe asks for the active charges and the mitigations you have applied, and Visa invites merchants to share source IP addresses, names, billing addresses, emails and user-agent strings.
9. Clean your data. Mark the attack period so reports and fraud models don’t treat test payments as customers.

What are the common mistakes?

• Relying on one control. A single IP rule is easy to beat, and it can block real customers behind a shared address.
• Protecting checkout but not save-card. Stripe says the card setup route is the one testers prefer.
• Running CAPTCHA on the page only. Stripe says it must be validated server side on every request that enables card validation or payment.
• Treating declines as harmless. Stripe’s guidance on block rules notes that issuers might lower your approval rates if you send a high number of failing transactions.
• Cascading the attack. Moving a suspect payment to the next provider multiplies the attempts. Our article on cascading and decline recovery explains why fraud declines should not be retried.
• Leaving limits tight forever. Emergency limits catch real customers. Review them once the attack ends.

How does Omno help stop card testing?

Omno scores every transaction for fraud and lets you act before a payment reaches a provider, with card blocking, customer blocking, blacklists shared across partner merchants and amount and volume limits per provider and method. The hosted checkout builder sets minimum and maximum amounts without a release, and the transaction trail shows every attempt, so you can see what an attack did. The risk controls page lists the settings.