For most of my career, card testing was the fraud problem nobody bothered talking about.
Every fraud team knew it existed. We’d see the sweep of $1 transactions on a quiet Tuesday morning, shrug, throw a velocity rule at it, and move on. The losses were trivial, if chargebacks were even reported. There were bigger fish to fry.
But in 2026, that changed.
This post is for merchants and acquirers who are starting to feel the squeeze, the ones suddenly seeing card testing show up in scheme program conversations, board decks, and escalation calls.
I want to walk through what card testing actually is, why fraudsters use it, why it matters now more than ever, and how to stop it without turning your fraud stack inside out.
How card testing actually works
The first thing to understand is that fraudsters don’t buy stolen cards one at a time. They buy them in bulk, by the hundreds, sometimes even thousands. There are three reasons for that.
First, bulk pricing. Stolen cards are a commodity, and like every other commodity, the unit price drops when you buy more. If you’re going to commit fraud at scale, and most professional fraudsters do, buying in bulk improves your ROI from day one.
Second, scale is just how they operate. Fraud at this level runs like a business: coordinated tooling, division of labor, and automated pipelines that can process thousands of cards in the time it takes a fraud analyst to write a rule. We've written more about how modern fraud operations are structured and scaled if you want the full picture. The point for now is that buying cards by the hundreds is just what the supply side of that operation looks like.
Third, and this is where it gets really interesting, many of those cards are already inactive by the time the fraudster receives them.
Here’s the thing: fraudsters defraud each other constantly. If I’m a hacker who steals 1,000 cards, there’s nothing stopping me from selling those same 1,000 cards to multiple buyers. And that happens. A lot. So when a fraudster buys a batch, a meaningful chunk of the cards in it may already have been used by an earlier buyer. The cardholder reported them, the issuer blocked them, and the cards are now worthless.
But the fraudster doesn’t know which cards are which. And this creates an ROI problem.
Imagine you’ve just bought 1,000 cards for a few thousand dollars. To monetize each one properly, you need a fresh device, a clean VPN session, a new email account, sometimes a new shipping mule. That setup costs real money and real time per attempt.
Now imagine you spin up that whole infrastructure for a card that turns out to be inactive. You just burned the setup for nothing.
This creates a bit of a Catch-22 for the fraudsters. On one hand, investing fully in every card significantly lowers the ROI. But on the other hand, investing nothing increases the chances you’ll fail monetizing the live cards you do have, again leading to reduced ROI.
The obvious solution to this is to test the cards first. You take all the cards in your batch and you systematically run very small transactions against them, typically a dollar, sometimes less.
The goal isn’t to monetize, but to find out which cards are still active. Cards that pass go into the “monetize” pile. Cards that fail get thrown away.
Because the goal of card testing is different from “classic” card fraud, it also tends to look different. Card testing often hits merchants you'd least expect. Fraudsters prefer to use low-scrutiny targets as convenient testing grounds, such as charity platforms that allow open-amount donations.
At the same time, most fraud detection systems are amount-sensitive by default. This is true at every layer, from the merchant and the PSP, to the acquirer and the issuer. A $1 charge passes through checks that would flag an identical $200 charge.
Fraudsters are not oblivious to either of those. The compounding effect means it’s easier for them to bypass fraud prevention systems much more easily.
That’s card testing: cheap, automated, infrastructure-light, and often invisible.
Three reasons card testing is now your problem
Until recently, the honest answer to this question was “you probably shouldn’t.”
If a fraudster runs 500 cards through your checkout at $1 a pop, your direct loss is $500. And that’s only if every test succeeds, which it won’t. Most test transactions are blocked at the card level anyway.
But there are three reasons you should care about card testing after all. Two of them were always true. One is new.
Reason one: VAMP changed the math
When Visa rolled out its unified fraud program, the Visa Acquirer Monitoring Program, or VAMP, it folded the previous Visa Fraud Monitoring Program and the Visa Dispute Monitoring Program into a single framework. More importantly, it added an explicit enumeration threshold that tracks fraud cases by count, not by dollar volume.
Under the old programs, a 500-card testing wave that produced $500 in losses was a footnote. But under VAMP, that same wave can push you across an enumeration threshold and into the program, which carries fines, scrutiny from your acquirer, and in some cases higher interchange fees.
Suddenly the financial cost of card testing is no longer the $500 you lost on the tests. It’s the penalties you incur because you enter the program. In extreme cases, you might even be dropped completely by your acquirer.
If you want the full breakdown of how VAMP calculates enumeration ratios, what RDR and CDRN now do (and don’t do), and where Compelling Evidence 3.0 fits in, our co-founder Zahid Shaik wrote a thorough piece on VAMP here.
I’m not going to re-iterate the mechanics here. What’s worth pulling forward is the part most card-testing conversations skip: the actual numbers.
Metric | Threshold | What triggers it |
VAMP Enumeration Ratio | ≥ 2,000 bps (both approved AND declined attempts) | Approved + declined auth attempts combined |
Minimum Enumeration Transaction Count | ≥ 300,000 enumerated authorizations (approved + declined) per month | Enumerated authorizations (approved + declines) |
Risk | Fines, acquirer scrutiny, higher interchange fees | Sustained card testing campaign within a single month |
The takeaway: VAMP also penalizes you on counts, not just on dollars. A merchant doesn’t need to be losing six figures to fraud to land in the program. They need a high enough ratio of enumerated authorizations to total authorizations, with a minimum volume floor, which a sustained card testing campaign can easily produce within a month.
The window to catch card testing is short, and shrinking with agentic AI
Reason two: Card testing contaminates your data
Most people don't talk about this one. But they should.
Here’s the thing about card testing transactions that pass, the ones that get authorized and settled. Most of the time, they never get charged back.
Why? Because it costs the real cardholder and the issuer more to file a chargeback than the $1 they might see in return. The cardholder may not even notice the charge.
So that fraudulent transaction sits in your dataset, unflagged, and over time it gets treated as legitimate. Now multiply that across tens of thousands of card testing transactions over months. You’ve taken a clearly fraudulent pattern, chock-full of small amounts, brand-new payment methods, no order history, and no reused shipping address, and unknowingly labeled it as good.
Your models and your rules now have a harder time separating fraud from non-fraud, because part of what they’re learning from is fraud that was never tagged.
That’s a slow, invisible degradation. By the time you notice your detection performance has slipped, you’ve already let a year of wrong labels into your training set.
Reason three: Card testing exposes the fraudster's infrastructure
This is the most interesting reason, and the one most teams don’t take advantage of.
Fraudsters don’t invest much in card testing. That’s the whole point of “testing”. So they tend to rely on cheap, exposed infrastructure to do it:
- IP ranges from known data centers or low-grade VPN providers
- Devices that don’t bother spoofing their fingerprints carefully
- Email domains used to mass-create disposable accounts in bulk
None of it costs much to spin up, and none of it costs much to throw away. That’s the surface they expose to you.
The play here is straightforward: block-list these assets. Some chunk of them will be reused, by the same fraudsters or by entirely different ones, in higher-value attacks against you.
Blocking them upstream doesn’t only prevent the cheap tests, but also a slice of the expensive attacks that follow.
Why card testing is easier to catch than most fraud
Card testing can be a pesky problem. But luckily, stopping it is one of the easier fraud problems to solve, once you’ve decided to take it seriously.
That’s not me saying it’s a non-issue, I just made the case for why it matters. It’s me saying that the typology of card testing makes it trackable in a way that most fraud problems aren’t.
Specifically, two things are true about almost every card testing campaign you’ll see.
First, it’s automated. It used to be script bots hitting an endpoint in a loop. The next wave we expect is agentic systems: more sophisticated, more adaptive, but still ultimately running at machine speed and machine scale.
The mode of attack will keep evolving, but the fact that it’s automated will not.
Second, the fraudsters can’t afford to constantly swap infrastructure. The whole reason they’re testing is to spend as little as possible per attempt.
If they had an unlimited budget for fresh devices, IPs, and email accounts on every test, they’d already be monetizing. So the same handful of devices, IPs, and email domains tends to show up across hundreds or thousands of attempts.
Put those two properties together, and the answer is a layered detection setup combining device and behavior biometrics (DIBB), with comprehensive velocity counters.
The DIBB layer catches the automation signal. When a “user” arrives with a tempered device fingerprint, with behavioral signals that scream script (no mouse movement, no realistic typing rhythm, identical session timing across attempts), the device tells the story before the transaction even hits authorization.
In parallel, the velocity layer catches the scale signal. How many auth attempts from this device in the last hour? How many from this IP across all our merchants? How many tests against the same BIN range? How fast are we cycling through new card numbers?
Each of those questions is cheap to answer and very informative when the answer comes back high.
Neither layer on its own is enough. A sophisticated bot can sometimes pass the device check. A patient fraudster can sometimes stay under velocity thresholds.
But the combination is the signature of card testing, full stop. If you have both layers wired together, you’ll catch the vast majority of card testing campaigns before they put a meaningful dent in your VAMP ratio.
When you go about it, here are a few notes on doing this well from an ex-practitioner:
- Don’t just block, tag. The infrastructure exposed during testing is intelligence you can use later. If your stack only blocks card testing without persisting what it learned, you’re throwing away half the value.
- Don’t set velocity thresholds against testing volume alone. Set them against the combination of testing volume and infrastructure overlap. “I saw 200 auth attempts from this IP” is one signal. “I saw 200 auth attempts from this IP, against 200 different BINs, all declined” is a complete picture.
- Don’t assume the fraudster will keep testing forever. The second they have what they need from the test phase, they’ll switch to monetization, usually with cleaner infrastructure, days or weeks later. The window to learn from the testing phase is shorter than people think, and with agentic AI in the mix, this window is getting ever smaller.
Where most fraud stacks fall short
Card testing isn’t the hardest fraud problem to solve, but solving it well at scale, with both DIBB and velocity layers actually wired together, is where most fraud stacks fall short. That’s where Sardine fits in.
The DIBB primitives I described are core platform capabilities: device fingerprinting that survives ID rotation, true IP detection that sees through VPNs and proxies, behavioral biometrics that distinguish humans from bots in real time.
On top of that, our velocity layer is configurable across whatever cut you need, whether it’s by device, IP, BIN, or account, across merchants and the consortium. And our consortium data means that infrastructure used to test cards on one customer is visible as risky on the next, before the first attempt.
That's the compounding advantage. Card testing exposes cheap infrastructure. Cheap infrastructure gets shared. And a network that learns from every merchant in it turns that exposure into a signal that benefits everyone.
