Test card fraud is the use of small payment attempts to check whether stolen card numbers work. The attacker keeps the numbers that return an approval and discards the rest. Charge amounts stay small, often under $2, so a failed test costs almost nothing.
What a test card is
A test card is a stolen card number that someone validates against a live merchant before resale or before a larger purchase. The check runs on a real payment page, not a sandbox. Numbers sold in bulk come with no guarantee, so buyers verify them first. A single approval raises the resale price of a number.
How a card testing attack runs
An attack needs a list of card numbers, a checkout that accepts them, and a way to send many requests. Attackers pick merchants with weak rate limits: donation forms, free trial signups, gift card pages, and stored-card features. Each request carries a different number and the same small amount. Approvals get sorted from declines, and the approved list goes back into circulation.
A BIN attack is a variant that generates numbers inside one issuer range instead of using a stolen list. The traffic looks like a burst of first-time customers from one region, all buying the same low-value item.
Signals merchants see
- Authorization attempts that jump 10x or more in an hour, with no matching traffic to the site
- A decline rate above 60% across one IP range or one device fingerprint
- Many card numbers tried against one account, one email domain, or one shipping address
- Orders for $0, $1, or another round figure, repeated across dozens of cards
- Billing addresses that pass the ZIP check and fail the street check
- Card numbers that fail the Luhn checksum, which means the number was invented, not stolen
What the authorization response shows
Response codes separate a random decline from a test run. Codes for pick up card and stolen card mean the issuer wants the card retained and the account closed. A cluster of do not honor responses inside a short window points to a script, not to one customer with a bad card.
Controls that reduce the exposure
- Set rate limits per IP, per device, and per card fingerprint. Count failed attempts, not only successful orders.
- Require address verification and card verification value checks on every checkout, including guest checkout.
- Turn off $0 and $1 authorization holds unless the business model needs them.
- Add a challenge step to guest checkout, where most test traffic lands.
- Watch approval rates by BIN and by hour. A BIN that approves 90% on one page and 40% on another is a signal.
- Escalate to 3-D Secure when a request scores high on velocity rules.
Why the loss arrives late
Card testing produces two costs. The first is fees on the test authorizations. The second is chargebacks, which land 30 to 90 days after the run. A merchant can block the traffic in week one and still absorb disputes in month two. Issuers also track the merchant account, not just the card, so a pattern of test traffic can raise the account's fraud score.
What the numbers do not show
Public estimates of card testing volume vary by source and by how each source defines an attack. No figure covers all processors, so treat any single number as a sample, not a total.