Card testing is running small, trial, or zero-dollar charges to find out which stolen cards are still live before committing to bigger fraud. It is usually automated against checkout or account-verification pages, turning a pile of stolen numbers into a shortlist of working ones.
What is card testing, in plain English?
Card testing is how fraudsters find out which stolen card numbers still work. A batch of stolen cards is mostly dead, because cards get reported, cancelled, or expire. Rather than risk a real purchase on a dead card, the fraudster runs a small, trial, or zero-dollar charge on each one and watches whether it approves. An approval means the card is live and worth using or selling.
The process is almost always automated. Scripts fire attempts against a checkout page or an account-verification endpoint, cycling through numbers quickly and keeping the ones that clear. The ideal target is any flow that returns a clean approve or decline for a tiny amount, which is why donation forms, free trials, and low-value stores get hit hardest.
Card testing is the same activity as card checking, and it is almost always a first step rather than the end goal. It converts a raw pile of stolen numbers into a validated shortlist. The actual loss usually happens later, and often at a completely different, higher-value merchant.
How a card-testing run works
- Load — Feed in stolen cards. A batch of numbers from breaches, phishing, skimming, or a carding shop is queued for testing.
- Fire — Automate tiny charges. Scripts run small or zero-dollar attempts against a soft checkout or verification endpoint.
- Sort — Keep the approvals. Cards that clear are marked live; declines are discarded, leaving a validated shortlist.
- Exploit — Cash out elsewhere. Confirmed cards are spent on real goods or sold, usually at a different, higher-value merchant.
Who is involved?
Who | Their role |
The tester | Runs the automated attempts to separate live cards from dead ones. |
The tested merchant | Hosts the endpoint being hammered. Pays the fees and decline penalties, rarely the final loss. |
The cashout merchant | A different, higher-value seller where the confirmed cards are actually used. |
The issuer and cardholder | See small odd charges and later the real fraud on the cards that tested live. |
What it looks like in practice
In practice
A small online store notices its payment metrics go haywire one afternoon. Thousands of tiny charges, many for a dollar or less, are flooding in over a few hours, most declining, all from a couple of devices cycling through different card numbers at machine speed.
This is a card-testing run using the store as a free validation tool. The store is not losing much on any single attempt, but its authorization fees are piling up and its decline rate is climbing toward the level that triggers its processor's monitoring program. Meanwhile, the handful of cards that approved are already being queued to buy electronics elsewhere. Adding a CAPTCHA and velocity limits to checkout ends the run within the hour.
Why it hurts even without a chargeback
It is tempting to dismiss card testing because the charges are tiny and the big loss lands elsewhere. That underestimates the damage. Every attempt costs you an authorization or gateway fee, a high-volume run can rack up real money, and a spike in declines drags down your approval rate and can push you into your processor's excessive-decline monitoring. You are also acting as free infrastructure for downstream fraud.
The behavior is machine-like and clustered, so it responds well to friction. The standard counters are velocity limits, CAPTCHA, device fingerprinting, and rate limiting on payment and verification forms. The aim is to make your endpoint slow, expensive, and useless as a testing tool, so the fraudster gives up before learning which cards are live and moves on.
What to watch in the data
- Tiny-charge spikes. A surge in small or zero-dollar transactions or verification calls in a short window.
- Rising declines. A jump in decline rate as mostly-dead batches get tested against your endpoint.
- Fast card cycling. Many distinct card numbers used rapidly from the same device, IP, or session.
- Fee and approval drift. Climbing authorization costs and a falling approval rate signaling automated abuse.
- Downstream reappearance. Cards that approved during the burst later showing up as chargebacks at other merchants.
Quick questions
Is card testing the same as card checking?
Yes. They are two names for the same activity: running small or zero-dollar charges to confirm which stolen cards are still live before using them for larger fraud.
Why do fraudsters test if the charges make no money?
The goal is not profit at this stage, it is information. Testing sorts a mostly-dead batch into a shortlist of working cards, which are then spent or sold for the real gain elsewhere.
Does card testing cost my business anything?
Yes, even without a chargeback. You pay authorization and gateway fees on every attempt, your approval rate falls, and a high decline ratio can trigger processor monitoring, which brings its own penalties and scrutiny.
Which pages get targeted?
Any flow that cheaply returns approve or decline: checkout pages, free-trial signups, donation forms, and account-verification endpoints. Low-value or unauthenticated flows are the most attractive because they are easy to automate.
What stops card testing fastest?
Friction and rate control: velocity limits, CAPTCHA, device fingerprinting, and rate limiting on payment and verification forms. The goal is to make your endpoint too slow and costly to serve as a testing oracle.
Go deeper
- EMVCo ↗ — Maintains the EMV chip and 3-D Secure specifications for card payments.
- PCI Security Standards Council ↗ — Security standards for handling cardholder data, including PCI DSS.