Card Testing Patterns: How Merchants Detect Stolen Card Attacks

A card testing pattern is a cluster of low-value authorization attempts across many card numbers in a short window, often from one device, IP range, or email domain. Merchants spot these patterns in decline rates, transaction velocity, and BIN concentration rather than in any single order. The pattern matters because a successful test tells a criminal the card is live, and the fallout lands on the merchant as chargebacks, fees, and network scrutiny.

What does a card testing pattern look like in practice?

Most card testing runs are loud in aggregate and quiet per transaction. One order for a dollar looks harmless. Two hundred of them in twenty minutes from the same subnet do not.

• Many small charges, often under $5, in a tight window.
• Decline rates far above your normal baseline.
• Cards from one bank identification number (BIN) or a run of sequential BINs.
• The same device fingerprint or email template across dozens of attempts.
• Billing addresses that fail AVS or change between orders.
• Purchases of gift cards, digital codes, or anything delivered in seconds.
• Traffic spikes at hours when your normal customers sleep.

Which parts of your data show the pattern first?

Authorization velocity

Velocity counts attempts per card, per IP, per device, and per email over a rolling window. Card testers burn through numbers fast, so per-IP and per-device velocity breaks first. If one address hits your gateway 40 times in an hour, that is not shopping behavior.

Decline rate spikes

Your baseline decline rate is a known number. A burst pushes it up in minutes and pulls it back down when the run ends. Alert on the change, not the absolute rate.

BIN and geography clustering

Watch for hundreds of attempts from a single BIN range, or cards issued in one country with IPs from another. A mismatch between issuing country, IP country, and billing country is a strong signal.

Reused devices, emails, and addresses

Testers recycle what works. One device ID tied to 30 cards, or email addresses built from the same template, links separate attempts into one campaign.

Why do card testers pick small merchants?

Large retailers run fraud teams, machine learning models, and years of labeled data. Small shops run default settings and manual review. Criminals test where resistance is thin and where a stolen number can be checked with a dollar purchase. Stores selling digital goods feel this hardest because the product ships before a chargeback arrives.

What does card testing cost the merchant?

• Interchange and gateway fees on transactions that never settle.
• Chargebacks, each with a fee that can exceed the order value.
• Higher reserve requirements or a frozen payout schedule.
• Fraud ratios that put your processing account at risk.
• Staff hours spent on review and customer complaints.

The hidden cost is the fraud ratio. Networks track the share of transactions that turn into fraud reports, and a small merchant with one bad month can lose the account that keeps the business running.

How do you stop a card testing attack?

1. Turn on CVV and AVS checks and decline mismatches instead of flagging them.
2. Set velocity limits per IP, device, email, and card, then hold anything above the limit for review.
3. Require 3D Secure on high-risk orders and first-time buyers.
4. Add a checkout challenge such as a CAPTCHA or a short delay after repeated failures.
5. Hold or review orders for gift cards and instant delivery during a burst.
6. Rate limit your payment API and your checkout endpoint.
7. Log everything: IP, device ID, user agent, email, BIN, and response code.
8. Report the attack to your processor and ask for a fraud rule review.

What should you do in the first hour of a burst?

Slow the traffic before you chase the orders. Rate limiting and a checkout challenge cut the volume while you work. Then pull the logs, group attempts by device and subnet, block what repeats, and void anything that slipped through. Call your processor early, since a fast report often changes how the incident is handled.

Is a declined card test a problem?

Declines still count as traffic against your account, and they inflate your decline rate. Some testers keep going until they find a live number, so a wave of declines often comes before a wave of approvals. Treat the first spike as the start of an attack, not background noise.

Does card testing mean my site was hacked?

Not usually. Most card testing uses stolen numbers bought elsewhere and pushed through your public checkout. Your database does not need to be breached for your store to be used as a testing ground.

How do you tell card testing apart from account takeover?

Account takeover uses one real account with a real password and changes the details inside it. Card testing uses many card numbers with little account history. The two often appear together, since a working card helps fund the takeover.

Reporting and follow-up

Keep a written record of the incident: start time, attempt count, response codes, and the actions you took. Send it to your processor and, for card-not-present fraud, to the fraud reporting channels run by the card networks. Repeat attacks on the same store are common, so leave your new rules in place after the traffic drops.