Card testing is a fraud tactic where someone sends a stream of small charges against stolen card numbers to learn which ones still work. Live numbers get saved for larger purchases later. Dead numbers get dropped, and the merchant absorbs the authorization noise.
For a merchant, the first sign is a burst of tiny orders, a spike in failed authorizations, or both. The chargebacks land weeks after the test run ends.
What does card testing look like on a merchant account?
Attackers favor small dollar amounts because many issuers approve a $1 charge without a challenge. They also favor digital goods, gift cards, and subscription signups, since those settle fast and ship nothing. One run can touch hundreds or thousands of card numbers in minutes.
Warning signs to watch for
- Dozens of orders from one IP address in a short window.
- Many orders sharing a card BIN, device fingerprint, or shipping address.
- A jump in declined authorizations, followed by chargebacks four to six weeks later.
- Order values clustered between $1 and $5 when your normal sale is much higher.
- Email addresses with random strings or disposable domains.
- Failed CVV or address verification on a large share of new orders.
- A pile of $0.00 or $1.00 authorization attempts in your gateway log.
Why do fraudsters test cards at all?
A stolen card list is a guess, not a verified product. Banks cancel cards in batches, and sellers rarely know which numbers are still active. Testing turns a blind list into a verified one, which raises the street price. That is why test charges stay small: the goal is a yes or no answer from the issuer, not revenue.
What is a BIN attack?
A BIN attack is a card testing run that stays inside one bank identification number. The attacker generates numbers from a known BIN range and works through them in sequence. Because every number shares an issuer, the pattern hides in normal traffic unless you track decline rate by BIN.
How do merchants stop card testing?
Layered defenses beat any single rule. Most payment processors already offer these tools, and turning them on costs little.
- Set velocity limits. Cap orders per IP, per card, per email, and per device per hour.
- Require CVV and AVS on every order. Decline mismatches instead of flagging them for manual review.
- Turn on 3-D Secure. The extra authentication step pushes most test traffic onto cards that fail.
- Add a CAPTCHA or bot check at checkout. Scripted runs stall when they hit one.
- Block or throttle known bad IPs, open proxies, and data center ranges.
- Watch authorization logs in near real time. A cluster of $0.00 to $1.00 attempts is a red flag.
- Set a minimum order value for digital goods delivered by email.
- Match the billing country to the card's issuing country for high-risk product types.
What should I do after a card testing attack?
Pull the order list and look for shared traits: IP, device ID, card BIN, email domain, user agent. Void or refund anything that has not shipped or been delivered, and cancel gift card codes that were issued during the window.
Report the pattern to your payment processor. They can add the BINs and IPs to a shared blocklist that protects other merchants too. If the volume is large, ask about a fraud monitoring program or a chargeback alert service.
Expect disputes to arrive weeks later. Answer each one with the order data, the AVS and CVV result, and a short note explaining the fraud pattern. Processors read those responses when they decide who pays.
Does card testing cost merchants more than fees?
- Chargeback ratios above card network thresholds can trigger fines or account termination.
- Issuers may flag your merchant descriptor, which leads to declines for good customers.
- Support costs climb when real orders sit buried under test traffic.
- Gift card balances and digital inventory can drain before anyone notices.
- Refund and dispute handling ties up staff time that produces no revenue.
Frequently asked questions
Is a cardholder charged when a test authorization fails?
No. A declined authorization costs the cardholder nothing and never appears on a statement. The $0 or $1 verification hold some merchants run is a different process, and that one does show up.
How fast does a card testing attack happen?
Most runs finish in minutes. Bots work through hundreds of numbers per second, so the window to react is short and manual review cannot keep up.
Can one setting stop card testing?
No. Velocity limits, CVV and AVS checks, and 3-D Secure work as a group. Any one of them alone leaves gaps that a determined tester will find.
Does 3-D Secure end card testing?
It raises the failure rate and the cost for the attacker, but some issuers still approve small charges without a challenge. Keep the other controls in place.
What card testing data should I keep?
Store IP address, device ID, card BIN, order timestamp, AVS and CVV results, and the authorization outcome for each attempt. Networks and processors ask for that data when you contest chargebacks or file a fraud report.
Do small merchants get targeted?
Yes. Attackers scan for weak checkout controls rather than big names. A store with no velocity limits and no CVV requirement is an easy target at any size.