Card checking is testing stolen card numbers with tiny or zero-dollar charges to see which ones still work before using them for bigger fraud. It is the same activity as card testing, and finding the live cards first saves the fraudster from wasting dead ones on a real purchase.
What is card checking, in plain English?
When a fraudster buys a batch of stolen card numbers, most of the batch is worthless: cards get reported, expire, or get cancelled. Rather than gamble a real purchase on a card that might be dead, they check each one first. Card checking is the act of running a very small or zero-dollar transaction, or an account-verification call, to confirm whether a card is still live and usable.
The check has to be cheap and low-friction, so fraudsters aim it at soft targets: a tiny charge that is unlikely to be noticed, a donation of a dollar, a small digital good, or a card-on-file verification that returns approve or decline without moving money. The signal they want is simple: does this card get a yes? A yes means the card is worth using or selling.
Card checking and card testing are two names for the same thing. It is almost always the first step in a larger operation. The confirmed live cards are then used for real purchases or sold on, and the actual loss usually happens at a different, higher-value merchant later.
How card checking runs
- Acquire — Get a batch of cards. Stolen numbers come from breaches, phishing, skimming, or dark-web purchase, most of unknown status.
- Probe — Run tiny or zero charges. Small verification charges or account checks are fired at a soft endpoint to see what approves.
- Sort — Keep the live cards. Approvals mark the working cards; declines are discarded. The batch becomes a shortlist.
- Cash out — Use or sell elsewhere. Confirmed cards are spent on real goods or sold, usually at a different merchant from the check.
Who is involved?
Who | Their role |
The tester | Runs the checking, usually automated, to sort live cards from dead ones. |
The checked merchant | Provides the low-value endpoint used to verify cards. Absorbs fees and declines, rarely the final loss. |
The cash-out merchant | A different, higher-value seller where the confirmed cards are actually spent. |
The issuer and cardholder | See small unexplained charges and, later, the real fraud on the cards that checked out. |
What it looks like in practice
In practice
A subscription app with a low-cost trial notices its authorization traffic jump overnight. Hundreds of one-dollar and zero-dollar verification charges are arriving in quick succession, most declining, a handful approving, all from a couple of devices cycling through different cards.
This is card checking. The app is being used as a free way to sort a stolen batch. The approvals are the fraudster's shortlist. The app itself loses only gateway fees and a bruised approval rate, but every card that approved here is about to appear as a real chargeback at an electronics retailer. Catching the pattern early and adding friction to the trial signup shuts the oracle down.
Why it matters to operators
The trap is treating card checking as someone else's problem because the charges are tiny. Even without a large loss on your own books, being the checking ground costs you real money in authorization and gateway fees, drags down your approval rate, and can push you into your processor's excessive-decline monitoring. You are also, in effect, providing free infrastructure for fraud that lands elsewhere.
Detection is workable because the behavior is machine-like and clustered. Velocity rules, decline-rate monitoring, and grouping attempts by device, IP, or session expose the pattern quickly. The aim is the same as with any testing attack: make your endpoint a poor and expensive place to check cards, so the fraudster moves on and, ideally, learns nothing useful before you cut them off.
What to watch in the data
- Small-approval spikes. A surge in tiny or zero-dollar charges or account-verification calls in a short window.
- High decline rate. Most attempts failing, because the batch being checked is mostly dead cards.
- Fast card cycling. Many different card numbers used rapidly from the same device, IP, or session.
- Off-hours automation. Machine-paced traffic at inhuman speed, often overnight, against signup or verification flows.
- Downstream matches. Cards that approved during the burst reappearing later as chargebacks at other merchants.
Quick questions
Is card checking the same as card testing?
Yes. They are two names for the same activity: running small or zero-dollar transactions to confirm which stolen cards are still live before committing them to bigger fraud.
Why use zero-dollar or tiny charges?
They are cheap and unlikely to be noticed by the cardholder, but they still return an approve or decline. The fraudster only needs that yes or no answer, not to actually move money at this stage.
Does the checked merchant lose money?
Usually not on the charge itself, but yes on fees and reputation. You pay authorization and gateway costs on every attempt, your approval rate falls, and a high decline ratio can trigger processor monitoring programs.
Where does the real fraud happen?
Almost always at a different, higher-value merchant. Checking is the sorting step; the confirmed live cards get spent or sold and generate their chargebacks elsewhere, which is why cross-merchant patterns matter.
How do you stop it?
Velocity limits, decline-rate monitoring, CAPTCHA or device fingerprinting on verification and signup flows, and rate limiting. The goal is to make your endpoint slow, costly, and useless as a card-checking tool.
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.