IOC card testing is the practice of using indicators of compromise (IOCs) to detect card-testing attacks, the automated process of firing large volumes of low-value payment authorizations to check whether stolen card numbers are still active. An IOC is any observable artifact in authorization logs, gateway responses, or network traffic that points to that automated behavior rather than to a real shopper.
Detection matters because card testing is the reconnaissance stage of payment fraud. Once testers confirm which numbers are live, those numbers move on to higher-value purchases, and the merchant that absorbed the test traffic usually absorbs the chargebacks as well.
What does IOC mean in the context of card testing?
In security work, IOC stands for indicator of compromise. NIST describes the term in its incident-handling guidance as evidence that a system, account, or dataset may have been accessed without authorization.
Applied to payments, an IOC is a measurable pattern rather than a single event. One declined 50-cent authorization means nothing on its own, but 4,000 of them from the same subnet inside 15 minutes is a clear signal.
Which signals are the strongest card-testing IOCs?
- Authorization velocity spikes. Hundreds of attempts per hour from one IP address, device fingerprint, or hosting ASN.
- Uniform micro-amounts. Transactions clustered tightly between 0.01 and 1.00 USD.
- Lopsided approval ratios. A large volume of declines with a thin slice of approvals mixed in.
- Sequential card numbers. Attempts that step through a narrow BIN range in numeric order.
- Repeated verification mismatches. AVS failures or CVV mismatches paired with fresh accounts and no order history.
- Session anomalies. Headless browsers, no pointer movement, and checkout completed in seconds.
- Geographic mismatches. IP country, billing country, and issuing country that do not align.
How does a card-testing attack create these indicators?
Attackers first enumerate numbers in bulk, often working through a purchased BIN range. They then submit low-value authorizations through scripted checkout requests to separate live cards from dead ones. Each automated attempt leaves a timestamped record, and the aggregate shape of those records is what detection teams work from.
Because the goal is speed, the traffic is rarely disguised well. Bots reuse the same user agents, hit the same endpoint in a fixed loop, and skip the normal browsing path that leads to a cart.
How fast should a team respond to a card-testing IOC?
Response windows are measured in minutes to hours, not days. Card networks and acquirers track merchant-level fraud and chargeback ratios, and sustained probing can push an account into monitoring programs with fees attached.
A practical sequence is to throttle or block the source at the edge, flag the affected BIN range for extra verification, and review any approved test transactions for follow-on abuse. Documenting the timeline also helps if the acquirer asks for a remediation report.
How do merchants reduce card-testing exposure?
- Set velocity limits per IP, device, and card fingerprint at checkout.
- Require CVV and enforce AVS on all card-not-present orders.
- Apply risk-based authentication such as 3-D Secure on suspicious sessions.
- Add bot detection or a challenge before the payment step, not after.
- Alert on decline ratios and micro-amount clusters instead of reviewing them monthly.
- Keep authorization logs long enough to reconstruct an attack after the fact.
Does 3-D Secure stop card testing?
It does not stop the attempts, but it changes their economics. Authentication challenges block most automated scripts, so testers move to merchants that do not ask for them.
Can card testing be eliminated entirely?
No. Any public checkout endpoint can be probed, so the realistic goal is to make probing expensive, noisy, and detectable early.
What is the difference between an IOC and a fraud rule?
An IOC is an observation drawn from real attack traffic. A fraud rule is the automated decision you build from that observation, such as blocking a session or forcing step-up verification.