Card Testing IOC: Indicators of Compromise to Detect Attacks

Card testing indicators of compromise (IOCs) are the observable signals that someone is running stolen card numbers through your checkout to learn which ones still authorize. They surface in three layers at the same time: infrastructure logs, payment gateway response data, and the behavior of the checkout session itself. Any one signal is weak on its own, but three or more firing inside the same short window is the threshold most fraud teams use to declare an active card testing campaign.

What are the core card testing IOCs?

The same handful of categories repeats across nearly every documented campaign.

• High authorization volume paired with a very low approval rate, frequently under 10 percent.
• Many distinct card numbers attempted against a single account, email address, or device fingerprint.
• Bursts of low-value charges, often under one dollar, used to confirm a card without tripping issuer limits.
• Repeated declines carrying the same response code, especially do-not-honor and stolen-card codes.
• Checkout sessions that submit the form in seconds, well below the human median.

What technical IOCs appear in server and CDN logs?

Infrastructure evidence is usually the first place a card testing IOC becomes visible.

• POST requests to the payment or tokenization endpoint with no prior page view and no referrer.
• Uniform User-Agent strings across thousands of requests, or a User-Agent that contradicts the declared browser capabilities.
• TLS fingerprints (JA3 or JA4) that stay constant while IP addresses rotate.
• Traffic concentrated in datacenter ASNs, residential proxy pools, or known bulletproof hosting ranges.
• Direct API calls that bypass the rendered checkout page entirely.

What do transaction-level card testing IOCs look like?

Payment data exposes the pattern even when the network layer looks clean.

• Card numbers arriving in near-sequential order within the same BIN range.
• Numbers that fail the Luhn check, which points to generated rather than leaked data.
• Address and CVV verification that never matches yet never stops the attempt.
• One billing address or phone number mapped to dozens of different card numbers.

How do card testing IOCs differ from ordinary fraud IOCs?

Classic payment fraud optimizes for merchandise and shipping value. Card testing optimizes for volume and speed, so the tell is velocity rather than order size, and the attacker often abandons the cart the moment a card authorizes.

What should you do when you confirm a card testing IOC?

1. Rate-limit or block the offending IP ranges, ASNs, and device fingerprints at the edge.
2. Force CAPTCHA, 3-D Secure, or step-up verification on the affected endpoint.
3. Notify your acquirer and payment processor so they can flag the BIN ranges involved.
4. Review interchange and gateway fees, since every declined attempt can still carry a cost.
5. Preserve logs and file a complaint with the relevant national fraud reporting center.

Frequently asked questions

Is one declined transaction a card testing IOC?

No. A single decline is normal commerce. It becomes an IOC only when it clusters with volume, velocity, and shared infrastructure signals.

How fast does a card testing campaign run?

Most bursts last minutes to a few hours, and many operators spread attempts across hundreds of IP addresses to stay under per-IP thresholds.

Do card testing IOCs require a data breach on my side?

Usually not. Attackers typically target publicly reachable checkout or subscription endpoints and supply their own stolen card data.