A card testing IoC is a measurable signal that someone is probing a payment endpoint to learn which stolen card numbers are still live. The strongest signals are bursts of low-value authorization attempts, elevated decline rates across consecutive card numbers, and many different cards sharing one IP address, device, or account. Catching these patterns early limits the fraud, the chargebacks, and the processor penalties that follow.
What are the most common card testing IoCs?
- Hundreds or thousands of authorization attempts in minutes, often against one merchant ID.
- Transaction values clustering at $0.00 to $1.50, including zero-dollar and one-cent authorizations.
- Decline spikes, especially "do not honor," "insufficient funds," and CVV or AVS mismatch response codes.
- Sequential or near-sequential card numbers and BIN ranges tried in order.
- One device fingerprint or browser session submitting dozens of different card numbers.
- Card-not-present orders where billing country, IP geolocation, and card BIN country disagree.
What does card testing look like in authorization logs?
In raw logs, a card testing run appears as a vertical wall of attempts with almost no settled sales. The authorization-to-settlement ratio collapses because most numbers fail, and the same payload repeats with only the PAN and expiration changing. Order confirmation emails, trial signups, and donation forms are frequent targets because they need no physical shipment.
Look for a high count of distinct card numbers per customer ID, per email address, or per shipping address. Attackers often reuse one account and swap cards until the account itself is flagged. That reuse is the thread that ties hundreds of failed attempts back to a single actor.
Which network and device signals point to card testing?
Traffic usually arrives from datacenter ASNs, residential proxy pools, or VPN ranges rather than ordinary consumer connections. Headless browser fingerprints, missing TLS or canvas fingerprints, and rapid session churn add weight to the pattern. Timing is another tell, with attempts spaced at machine-regular intervals instead of human pacing.
How do you tell card testing apart from normal decline noise?
Normal declines are spread across a day and tied to identifiable customers with order history. Card testing clusters tightly in time, concentrates on new accounts, and shows a card-to-customer ratio far above baseline. Compare the current hour against a rolling seven-day median for the same endpoint to separate a real spike from daily variation.
What should you do once you confirm card testing?
- Block the source IPs, device fingerprints, and accounts involved, then throttle the abused endpoint.
- Preserve authorization logs, headers, and payloads before they rotate out of retention.
- Notify your acquirer and payment processor so they can suppress the BIN range and adjust fraud rules.
- Void or refund any successful micro-charges before they turn into disputes.
- Report the activity to the card networks and to the FBI Internet Crime Complaint Center.
How do you prevent card testing before it reaches your processor?
Apply velocity limits per IP, per device, and per card BIN, and require 3-D Secure step-up on risky attempts. Add CAPTCHA or bot detection to any page that accepts a card number without a login. Monitor authorization volume continuously and alert on low-value bursts rather than waiting for the monthly chargeback report.
Frequently asked questions
Why do card testers use small amounts?
Small amounts reduce the chance the real cardholder notices and lower the cost of a failed attempt. A live card that approves one cent can then be sold or used for a larger purchase.
How long does a card testing burst usually last?
Most bursts run from a few minutes to a few hours before the attacker moves to a new target. Some campaigns spread low-volume attempts over weeks to stay under fixed thresholds.