Payments, retention and operations
Card testing: how to spot a carding attack, stop it and clean up after it
Card testers don't want your product. They want to know which stolen card numbers still work, and your checkout answers them one attempt at a time. The fraud reports, disputes and declines on real buyers that an attack leaves behind outlast the attack itself, so cleaning up matters as much as the defenses.
Reading pathPart 6 of 8 · Getting paid, from the CTA click to the bank
- Checkout Abandonment: Why Buyers Leave, How to Fix It
- Trust Badges: Which Help at Checkout and Which Mislead
- How Payment Processing Works, From Pay to Payout
- Payment Authorization Rate: Declines and Retry Rules
- 3D Secure: Liability Shift, SCA and When to Use It
- Card Testing: How to Spot and Stop a Carding Attack
- Chargeback Representment: How to Win a Chargeback
- How to Reduce Chargebacks: Fix Each Dispute Reason
On this page
Card testing is fraud: someone runs stolen card numbers through a checkout, usually with a script, to learn which cards still work. It shows up as a burst of declines, small payments under made-up names and emails, and failures piling up from the same IP addresses or one BIN range. Stop it with bot checks and rate limits on the payment step, then cancel and refund what got through.
Here's what three hours of it can look like at an illustrative store that sells a free bottle for a $9.95 shipping charge:
Payment attempts per hour on the night of an attack
Illustrative store, one day
- Declined
- Approved
Hour of the day
Show the numbers
| Hour of the day | Declined | Approved |
|---|---|---|
| 00:00 | 1 | 9 |
| 01:00 | 1 | 6 |
| 02:00 | 96 | 5 |
| 03:00 | 418 | 21 |
| 04:00 | 275 | 14 |
| 05:00 | 2 | 4 |
| 06:00 | 1 | 6 |
| 07:00 | 1 | 9 |
| 08:00 | 2 | 12 |
| 09:00 | 2 | 15 |
| 10:00 | 2 | 17 |
| 11:00 | 3 | 18 |
| 12:00 | 2 | 20 |
| 13:00 | 3 | 19 |
| 14:00 | 2 | 17 |
| 15:00 | 2 | 16 |
| 16:00 | 2 | 18 |
| 17:00 | 3 | 21 |
| 18:00 | 3 | 24 |
| 19:00 | 3 | 27 |
| 20:00 | 4 | 29 |
| 21:00 | 3 | 26 |
| 22:00 | 2 | 19 |
| 23:00 | 2 | 13 |
How a card testing attack works
Stripe defines card testing as someone trying to find out whether stolen card information is valid, and lists the other names it goes by: carding, account testing, enumeration and card checking. Testers use scripts to try many cards at once and read the answers that come back from the issuer or from 3D Secure. The cards that pass are then used for purchases or resold (Stripe).
Stripe says two kinds of checkout step attract them: saving a card, because a card validation at setup doesn't usually appear on the cardholder's statement, and small payments. Visa's guidance for merchants puts a number on small: attack transactions are "often less than $10 USD" (Visa).
That profile fits parts of a VSL funnel that look harmless:
- A shipping-only charge. The $9.95 on a free-plus-shipping offer sits just under Visa's $10.
- A free trial that checks the card. A validation at sign-up, with the first real charge weeks later, is the card-setup pattern Stripe describes.
- A checkout with its own address. Your checkout runs on your store platform or your processor's page, and a script can be pointed straight at it without ever loading the VSL.
That last point matters later: attempts that skip the video leave a gap between your payment numbers and your video numbers.
The signs of card testing, and how they differ from a bad day of declines
Between them, Stripe's documentation and Visa's June 2026 guidance point to these signs:
- A spike in failed or blocked payments, often generic declines that give no reason.
- Many low-value payments, often with nonsense names and emails.
- Approvals or declines clustered in one BIN range, the first digits of the card number, which identify the issuing bank.
- Repeated failed payments from the same IP addresses. Visa suggests blocking addresses that keep failing.
- One account logging in from many IP addresses.
- Mismatches between the browser and the connection, such as a time zone or language that doesn't fit the IP address or the device.
- A rise in reversals, approved authorizations that get canceled.
None of these proves an attack on its own. A funnel that buys its traffic sees more declines every time a campaign scales, and an issuer can turn down a run of good cards for reasons that have nothing to do with bots. In the illustrative store above, the approval rate for the whole day reads 31.6%, but outside the three attack hours it was 88.2%. Judge declines as a share of attempts and against the traffic you sent, not as a count.
The quickest test is whether real buyers came with the declines. In RevvyScales, the Live view shows plays, CTA clicks and sales as they happen (the Live view). If your processor is logging several payment attempts a minute while this screen shows no checkout clicks in the last five minutes, those attempts didn't come from people who watched your VSL, unless you also send buyers to the checkout from somewhere else, such as an email:
- Visitors right nowThe first card counts who is watching your VSLs at this moment and who is at checkout.
- The last five minutesPlays, checkout clicks and sales in the last five minutes, to set against the attempts your processor logs.
Put the signs together and most spikes sort themselves out in two or three questions:
Card testing or an ordinary decline spike?
Did CTA clicks and checkout visits rise along with the declines?
Compare the same hours in your VSL analytics or the Live view.
Did the approval rate per attempt hold near its usual level?
Do the failed attempts share small amounts, made-up names or emails, a few IP addresses or one BIN range?
Best fit
More traffic, more declines
Clicks rose with the declines and the approval rate per attempt held, so the extra declines came with extra buyers. Nothing needs stopping; keep judging the rate, not the count.
Best fit
Treat it as card testing
More real traffic doesn't explain the declines, and the failed attempts carry a script's marks: small amounts, made-up names, a few IP addresses or one BIN range. Raise friction, call your processor and hold the attack window's orders.
Best fit
An ordinary decline problem
More traffic doesn't explain the declines, but the failed attempts look like real buyers: ordinary amounts and names, many addresses. Read the decline codes and split approvals by BIN and issuer country.
Read more: Payment Authorization Rate: Declines and Retry Rules
If the answer is an ordinary decline problem, the fixes are different: read the decline codes and split your approval rate by card brand, BIN and issuer country.
What card testing costs after the attack stops
Visa says enumeration "leads to $1.1 billion annually in fraud losses" (Visa). For one store, the declined attempts are the cheap part. Stripe lists what follows an attack (Stripe):
- Fees on attempts. Depending on your pricing, you may pay for attempts that never become sales. Stripe mentions authorization fees on custom pricing plans, plus dispute fees.
- Fraud reports and disputes. Every approved test is a charge on someone's stolen card. When the owner or the bank notices it, the issuer can report it as fraud, which processors call an early fraud warning, and the cardholder can dispute it.
- Declines on real buyers. A high decline rate can hurt your standing with card issuers and networks, and Stripe warns that legitimate payments can keep getting declined more often "even after card testing ceases".
- Numbers you can't trust, and extra load on your systems.
The fraud reports are the part that lasts. Stripe says about 40% of Visa and Mastercard early fraud warnings become fraud disputes when the charge isn't refunded, and that refunding a flagged payment doesn't remove the warning (Stripe). Visa counts fraud reports alongside disputes in its monitoring ratio, and enough of either can bring a merchant into the networks' monitoring programs. Dispute rate is also one of the factors Stripe weighs when it sets a reserve.
Take the 27 test charges that went through in the illustrative night, at $9.95 each. Refunding all of them costs $268.65, money that was never yours, since the cards were stolen. Each one left alone can still turn into a dispute that costs the $9.95, a $15 dispute fee on a US Stripe account and a place in your ratio. Stripe's own analysis puts the point where refunding a flagged charge pays at roughly your dispute fee or below (Stripe), and $9.95 sits well under $15. Ship the free bottles too and you add product and postage on 27 parcels nobody wanted, $283.50 at the free-plus-shipping example's $10.50 an order.
How Visa counts card testing
Visa's acquirer monitoring program, VAMP, watches card testing on a track of its own, separate from disputes and fraud. An account is flagged only when it crosses two lines in the same month:
How Visa's VAMP measures card testing
Enumeration ratioenumerated authorization attempts (approved + declined) ÷ all authorization attempts (approved + declined), in one month
Excessivea ratio of 20% or more and at least 300,000 enumerated attempts in the same month
Illustrative: a script sends 60,000 attempts in a month to a store that otherwise sends 40,000. The ratio is 60,000 ÷ 100,000 = 60%, three times the line, but 60,000 is far below 300,000, so the store is not flagged. Fraud reports on the cards that worked still count in its dispute and fraud ratio.
The 300,000 floor means only big targets reach the threshold, and Stripe says Visa doesn't assess fines for its enumeration monitoring (Stripe). That doesn't mean Visa ignores small stores. Its June 2026 guidance says "All VisaNet clients are monitored for enumeration", and its fact sheet says VAMP requires acquirers to take proactive steps to keep their merchants under the thresholds. In practice, any pressure reaches you through your processor and its acquirer, whatever your count.
How to stop card testing at the payment step
Start with Stripe's warning: simple firewall rules or filters built on one signal, such as blocking by IP address alone, are usually not enough. The defenses that work come in layers, and Stripe and Visa list much the same ones:
- A bot check where cards are used. Put a CAPTCHA on every request that validates a card or takes a payment, and check it on the server. Stripe suggests combining rules: a first attempt goes through freely, later attempts from the same IP address need the CAPTCHA.
- Limits on speed and volume. Cap new customers per IP address per day, cards tried per account or session, and customers per address. Visa adds velocity limits on amounts and counts by IP address, device and email.
- Card checks on every payment. Visa recommends making the CVV and the address check mandatory on card-not-present payments, and processor rules such as Stripe's Radar rules can act on failed CVC checks and on velocity.
- Tools that see past a script. A web application firewall with anti-bot tools, and device fingerprinting that can see through proxies.
- Less to learn from each failure. J.P. Morgan's merchant guidance recommends giving less detail in payment error messages, and using caution with BIN blocking (J.P. Morgan). A BIN range belongs to a bank, and your real buyers bank there too.
- 3D Secure on risky attempts. Visa lists it among the controls. Use it as a step-up on the orders that warrant it, not on every buyer.
- Safe keys. Keep your processor's secret keys safe, and roll your API keys if an attack came through your API.
On a VSL funnel, most of these controls live in someone else's software: your store platform's checkout, your processor's fraud settings or its hosted payment page. Stripe, for one, builds rate limiters and CAPTCHA triggers into its own checkout integrations. Ask your checkout platform and your processor which of these they offer and which are switched on, and protect the small-amount steps first: the shipping-only charge and any trial that validates a card.
Every layer adds a little friction for real buyers too. Keep a baseline running all the time, and raise it when an attack starts rather than living at maximum.
What to do during an attack, in order
Speed matters for a reason specific to fraud reports. On Stripe, the only refund that can prevent a fraud report is one processed as a reversal, which usually happens within about two hours of capture. After that, the report can arrive whatever you do. Work through these steps in order:
Responding to a card testing attack
1Confirm it is an attack
What happens: Set the payment attempts against your CTA clicks for the same hours, and look for the marks: small amounts, made-up names, repeated addresses, one BIN range.
Why it matters: An ordinary decline spike needs other fixes, and blocking real buyers on a guess loses sales you paid for.
What goes wrong:
- Counting declines instead of the rate per attempt
- Forgetting buyers who reach the checkout without the VSL, such as from email
2Raise friction at the payment step
What happens: Tighten the CAPTCHA, block the attacking IP addresses and ranges, lower velocity limits and add temporary step-up checks such as 3D Secure.
Why it matters: J.P. Morgan advises blocking attacking addresses and ranges and considering temporary step-up controls; Stripe warns that one signal alone is usually not enough.
What goes wrong:
- Blocking whole BIN ranges and turning away real buyers
- Keeping attack-level friction long after the attack ends
Read more: 3D Secure: Liability Shift, SCA and When to Use It
3Call your processor
What happens: Give it the time window, the addresses and what you switched on, and ask what it can tighten on its side. Roll your API keys if the attack came through your API.
Why it matters: Visa requires acquirers to act against enumeration, so your processor has reasons of its own to help.
What goes wrong:
- Waiting for the processor to notice first
4Cancel and refund what got through
What happens: Void approvals you have not captured, refund the test charges, and cancel every unshipped order from the attack window that carries the marks.
Why it matters: Stripe advises refunding fraudulent payments to avoid disputes, and on Stripe a refund processed as a reversal, usually within about two hours of capture, can prevent the fraud report.
What goes wrong:
- Shipping orders placed during the attack
- Retrying the cards an attacker set up
Read more: How to Reduce Chargebacks: Fix Each Dispute Reason
5Watch the next few weeks
What happens: Track early fraud warnings, disputes and real buyers' approval rate, and keep the extra friction until the attempts stop.
Why it matters: Reports and disputes on the charges that went through arrive later, and declines on legitimate payments can stay high after the testing stops.
What goes wrong:
- Removing the controls the morning after
Read more: Chargeback Ratio: How Visa and Mastercard Count It
Two mistakes make an attack worse. Don't retry the cards an attacker set up: Stripe warns that this repeats the original attack. And keep your own subscription retries on the schedule the decline codes allow, because Stripe also notes that aggressive dunning, in spikes with a low success rate, can look like card testing.
One more control deserves a second thought. J.P. Morgan suggests considering accounts in place of guest checkout during an attack. That adds a step for every real buyer arriving from your ad, so save it for an attack that outlasts the other controls, and take it off when the attempts stop.
Before the next attack: a checklist
Most of this is settings in your checkout platform and your processor, plus one phone call:
Card testing defenses for a VSL checkout
0 of 10 done
Once the defenses are in, check your declines per hour every week, so you know what a normal night looks like before the next abnormal one.
Frequently asked questions
Can Visa fine me for card testing on my store?
Not under the enumeration track of Visa's monitoring program. Stripe says Visa doesn't assess fines for VAMP enumeration monitoring, which only flags accounts with at least 300,000 enumerated attempts and a 20% ratio in a month. The fraud reports from cards that went through count in VAMP's other track, for disputes and fraud. The rest of the cost is fees on attempts, disputes and more declines on real buyers.
Why would fraudsters test stolen cards on my store?
Because your checkout tells them whether a card works. Stripe says testers favor two kinds of step: saving a card, since a validation at setup usually doesn't appear on the statement, and small payments. Visa says attack transactions are often under $10. A shipping-only charge or a trial that validates a card fits that profile, whatever the store sells.
Should I refund payments that went through during a card testing attack?
Yes. Stripe advises refunding fraudulent payments to avoid disputes, and refunding a small test charge costs less than a dispute on it, which on a US Stripe account adds a $15 fee and counts in your ratio. Move fast: on Stripe, only a refund processed as a reversal, usually within about two hours of capture, can prevent the fraud report.
Will blocking the attacker's IP address stop card testing?
Usually not on its own. Stripe warns that simple firewall rules or filters built on a single signal, such as IP address alone, are usually not sufficient. Block addresses that keep failing, as Visa suggests, but combine it with a CAPTCHA on payment requests, rate limits by device and email, limits on cards per customer, and your processor's velocity rules.
Does 3D Secure stop card testing?
It helps, but it isn't a cure. Visa lists 3D Secure among the controls against enumeration, and J.P. Morgan suggests temporary step-up checks during an attack. Stripe notes that testers also read the answers that come back from 3D Secure, so use it as one layer next to bot checks, rate limits and card checks, and expect some friction for real buyers.
Sources
- Protect yourself from card testing — Stripe Docs
- Enumeration Mitigation and Considerations for Merchants (V1.3, June 2026) — Visa
- Visa Acquirer Monitoring Program Overview (fact sheet, 2025) — Visa
- Introducing the Visa Acquirer Monitoring Program — Visa
- Dispute and fraud card monitoring programs — Stripe Docs
- How disputes work — Stripe Docs
- Card testing 101: Spot it early, stop it fast (9 July 2026) — J.P. Morgan Payments
- Reserves: frequently asked questions — Stripe Support