Card Testing Attacks: How Bots Use Your Checkout to Validate Stolen Cards, and How to Stop Them

A card testing attack is a bot running hundreds or thousands of stolen or guessed card numbers through your checkout to find out which ones still work. The fraudster is not trying to buy anything from you. Your payment form is the tool, and the valid cards it confirms are sold on or used somewhere else. Visa, which monitors every card-not-present authorization on its network for this pattern, puts the resulting fraud losses at over a billion dollars a year across the payments ecosystem.

For a high-risk merchant the damage is not abstract. Every test is an authorization you pay for, every test that succeeds becomes a fraud report or a dispute against your account, and Visa's Acquirer Monitoring Program now measures enumeration as its own category alongside fraud and chargebacks. One bad weekend can push a clean account over the thresholds that get merchant accounts terminated. This guide covers what card testing is, what it actually costs, how Visa counts it, and the defenses Visa and the major processors recommend, as of Visa's June 2026 merchant guidance.

What a Card Testing Attack Actually Is

Visa's term for the practice is enumeration, and its definition is precise: a fraudster systematically tests or guesses payment credentials, such as card numbers, expiration dates, CVV2 values, or postal codes, to identify which are valid and can later be used for fraud. Visa calls it a leading indicator or precursor to downstream fraud. Stripe's documentation lists the other names for the same thing: carding, account testing, card checking.

The card numbers come from two places. Some are bought in bulk as stolen data, and the bot is checking which have not yet been cancelled. Others are generated: the attacker takes a known bank identification number, the leading digits shared by every card an issuer prints, and enumerates the remaining digits, expiry dates and security codes until the issuer approves one. Visa notes that bots also enumerate the postal code used for address verification, which is why a merchant that only checks the ZIP is not protected by it.

Attacks take two shapes, and the distinction matters for where you put your defenses:

• Save-card attacks. The bot hits the endpoint that adds a card to an account or wallet, which triggers a zero-dollar account verification request to the issuer. Stripe notes this is the method fraudsters prefer, because those verifications do not typically show up on cardholder statements and so are less likely to be noticed and reported.
• Small-payment attacks. The bot places real orders for tiny amounts. Visa's guidance says attack transactions are often less than ten dollars, and that fraudsters sometimes send a reversal the moment an authorization is approved, so the charge never settles and the cardholder never sees it.

Why It Lands on High-Risk Merchants

Visa lists four routes into the payment system: merchant accounts opened under synthetic identities, takeover of a real merchant's gateway login through phishing, cloned point-of-sale devices, and, the most common, legitimate eCommerce merchants that have weak fraud controls in place. It also singles out one merchant type by name: sites that accept donations or a free-text payment amount, which fraudsters have specifically targeted because the bot can choose an amount small enough to go unnoticed.

High-risk merchants tend to combine several of the traits bots look for: direct gateway integrations rather than a hosted checkout with built-in rate limiting, guest checkout with no login step, low-ticket digital goods and trial sign-ups where a small first charge looks normal, and a history of stripping friction from checkout to protect approval rates. Together they make a payment form a script can hit thousands of times an hour with nothing in its way.

What Card Testing Costs, Even When Every Test Is Declined

The obvious losses are the tests that succeed and turn into chargebacks. The larger bill is usually elsewhere.

Authorization fees on every attempt

Each test is an authorization request, and authorizations cost money whether or not they are approved. Your gateway typically charges a per-transaction fee on every attempt, and network and acquirer fees accrue on that traffic too. Visa's guide is explicit that enumeration increases processing fees for acquirers and issuers and adds system integrity fees for acquirers on non-compliant authorization attempts; those costs are passed down. Stripe likewise warns of additional fees, such as authorization fees on custom pricing plans, and dispute fees. Ten thousand declined tests overnight is ten thousand billable authorizations.

Mastercard's Transaction Processing Excellence fees

Mastercard runs two fees under this program built around exactly this pattern. The Excessive Authorization Attempts fee applies to repeated authorizations on the same card at the same merchant after a run of declines, and Mastercard's own illustrative example when the fee launched was a fraudster using a bot to make purchase attempts repeatedly to test whether a card number is valid. The Nominal Amount Authorization fee applies to card-not-present authorizations of a dollar or less that are approved and then reversed. Both have been raised since they were introduced in 2019 and are passed through at rates that vary by processor, so the number that matters is the one on your own fee schedule.

Fraud reports and disputes that count against you

Tests that succeed and settle are eventually noticed by cardholders. Each becomes a fraud report from the issuer, what Stripe surfaces as an early fraud warning and Visa records as a TC40, and many become disputes. Visa's VAMP ratio is the count of fraud reports plus disputes divided by settled card-not-present transactions, so a successful attack inflates the numerator on both sides at once. A high-risk merchant that normally runs well under Visa's 1.5 percent excessive-merchant threshold can be pushed over it by one campaign, and it is the acquirer's stricter internal limit, not Visa's, that decides whether the account survives.

Stripe also describes a cost that outlasts the attack: a large number of declines associated with your business can damage its reputation with issuers and networks, raising the decline rate on legitimate payments even after the card testing stops.

How Visa Counts Enumeration Under VAMP

Visa's program fact sheet defines two enumeration metrics, both counted on authorizations rather than settled sales, so declined tests count:

• VAMP Enumeration Ratio: the count of enumerated authorization transactions, approved and declined, divided by the count of all authorization transactions, approved and declined. The threshold is 2,000 basis points, or 20 percent.
• VAMP Enumeration Transaction Count: at least 300,000 enumerated transactions in the month.

The 300,000 floor means the enumeration track itself is aimed at very large merchants and at acquirers, which Visa requires to take proactive steps to keep their merchants under the thresholds. It is still relevant at any size: Visa states that all VisaNet clients are monitored for enumeration and that it engages the stakeholders when a case is identified, which in practice means your acquirer hears about your traffic. And the fraud and dispute half of VAMP bites at 1,500 monthly events, which is exactly the count a successful campaign feeds.

Visa identifies enumerated transactions with its Visa Account Attack Intelligence Score, which analyzes every card-not-present transaction on VisaNet in real time and returns a score from 01 to 99, with high values indicating that credentials are likely being enumerated. When Visa announced the score in May 2024 it said that 33 percent of enumerated accounts experienced fraud within five days, which is why the network treats card testing as fraud in progress rather than a nuisance. Visa's guidance says merchants can incorporate the score into their fraud strategy and use a high value as a trigger to void or refund the transaction.

How to Recognise an Attack in Progress

Most attacks are visible in your gateway reporting if you know what to look for. The signals Visa and Stripe both point to:

• A sudden spike in failed, declined or blocked payments against a flat baseline of legitimate orders. Visa says spikes in declines should be investigated as a sign the business has become a target.
• Approvals or declines clustered in a similar BIN range, the signature of a bot walking through one issuer's card numbers.
• Low-value payments with nonsensical customer names and email addresses, often from one device or IP address across many different cards.
• An increase in reversals arriving immediately after approvals.
• Time zone or browser language that does not match the IP address or the card's country.
• For API integrations, a spike in card-error responses, which Stripe describes as a jump in 402 errors and generic decline outcomes.

If you see this, stop the bleeding before you analyze it: identify the activity, refund any payments that got through so they do not become disputes, add controls to the endpoint being hit, then monitor to confirm they are working.

The Defenses Visa and the Processors Actually Recommend

No single control stops card testing. Stripe is blunt that simple firewall rules or filters based on a single heuristic such as IP addresses are usually not sufficient on their own, because attackers rotate through proxies and botnets. Visa's guidance and the processors' converge on a layered set:

1. Put a CAPTCHA on every request that can validate a card or make a payment, validated server-side. Visa is specific that it must cover all requests that enable card validation or payments, not just the visible checkout button. Modern invisible CAPTCHAs add little friction for real customers.
2. Set velocity thresholds on more than one data element: per IP address, device, email and card within a set timeframe. Visa's own example is five authorizations from one IP or one card number, and it specifically calls for velocity checks on low-amount and authorization-only transactions, because that is where the tests live.
3. Require CVV2 and AVS on every card-not-present authorization, and do not treat a transaction as verified when either fails. Visa notes that fraudsters seek out merchants that accept authorizations without them.
4. Lock down the save-card path as tightly as the checkout: rate limiting at the add-card step, limits on cards added per account and per session, limits on accounts created per IP address, and blocking of excessive failed account verification attempts.
5. Set a minimum amount on donation and free-text payment forms. Visa recommends the highest minimum still appropriate for most donors.
6. Require a login or validated session before the payment form, and protect it with CSRF tokens, which both Visa and Stripe note defeat the simpler automated attacks.
7. Use 3-D Secure, device fingerprinting with proxy piercing, and a web application firewall with bot management. Fingerprinting is what lets you see that a hundred different cards are coming from one device.
8. Adopt network tokens with domain restrictions, which Visa's June 2026 guidance adds to the list: a token restricted to your merchant is worthless if stolen.
9. Protect your gateway credentials. If tests are hitting your API directly rather than the web form, roll your API keys, and watch for phishing aimed at gateway logins.
10. Refund what got through, and do not retry it. Visa and Stripe both advise refunding fraudulent payments to avoid disputes, and Stripe warns subscription merchants not to keep retrying cards saved by fraudulent sign-ups, because that repeats the original attack.

Visa also asks that attack details be shared so it can attribute threat actors: source IP addresses, the names and billing addresses used, email addresses, and the user-agent header. In practice, route that through your acquirer, who is the party Visa will contact about your account anyway.

What to Ask Your Processor

The controls above are split between your integration and your provider, and it is worth knowing which is which before an attack rather than during one:

• Does the gateway apply its own rate limiting and CAPTCHA, or is that entirely on my integration?
• Are fees on declined authorizations itemized on my statement, and which Mastercard Transaction Processing Excellence fees are passed through, at what rate?
• Will you alert me on a spike in declines, and what happens to my settlement and reserve if an attack hits?

PayKings places high-risk merchants with acquiring banks that expect card-not-present risk and underwrite for it, on dedicated merchant accounts rather than shared aggregator IDs, with gateways that support the velocity controls, CVV and AVS enforcement, and 3-D Secure that Visa's guidance calls for. If your checkout has become a card testing target, or you want to close the gap before it does, reach out.