What Counts as an Indicator of Compromise for Card Testing
Card testing leaves a trail in your authorization logs. The core indicators of compromise are a burst of low-value authorization attempts, a decline rate far above your baseline, several card numbers arriving from one IP address or device fingerprint, and cards that pass the issuer check but fail address verification. Any single signal can be ordinary noise. Two or more arriving together inside a short window is the pattern that matters.
How to Use IOCs for Card Testing
Card testing is a numbers game. Someone holding a list of card numbers needs to learn which ones still authorize, and the cheapest way is to push many small charges through a live checkout, then keep whatever returns an approval. Your gateway records every one of those attempts, whether it succeeds or not.
Prerequisites
- Read access to gateway authorization logs with response codes.
- Transaction records that include IP address, device fingerprint, and email.
- A baseline of normal approval and decline rates for your store.
- Authority to block IPs, disable accounts, and change fraud rules.
Step-by-Step Detection
- Export authorization attempts from the last 72 hours with response codes, timestamps, and card BINs.
- Group the export by IP address.
- Count attempts per IP inside any 10 minute window.
- Flag every group with more than three attempts in that window.
- Calculate the decline rate for each flagged group.
- Compare that rate against your 30 day store baseline.
- Repeat steps three through six using device fingerprint instead of IP.
- Sort flagged cards by BIN and note any BIN that appears across unrelated IPs.
- Pull AVS and CVV response codes for every approval inside a flagged group.
- Flag approvals where AVS fails but the issuer still authorizes.
- Check for clusters of near-identical small order values.
- Match flagged email addresses against a disposable domain list.
- Record each confirmed cluster with timestamps, IPs, fingerprints, and BINs.
- Escalate the record to your fraud team or payment processor.
Behavioral and Infrastructure Signals
- Sessions from one IP or a narrow IP range within minutes of each other.
- Card numbers that run in sequence inside a single BIN range.
- Checkout sessions that skip product pages and land on payment.
- One user agent repeated across dozens of accounts.
- Email addresses on domains registered in the same week.
- Billing details that repeat while cardholder names change.
- Traffic spikes during hours when your real customers sleep.
Response Steps After You Confirm an Attack
- Block the offending IPs and device fingerprints at the edge.
- Void or refund authorizations that have not settled yet.
- Disable the accounts tied to flagged email addresses.
- Raise velocity limits for the affected BIN ranges.
- Enable 3D Secure on high-risk transactions.
- Send the cluster record to your payment processor.
- Report the incident to your card network if the volume is high.
- Re-check the same cluster 24 hours later for repeats.
Common False Positives
Some legitimate traffic looks like card testing. Corporate networks route hundreds of employees through one IP. Gift card buyers place many small orders in a row. A retry loop in your own checkout can generate repeat attempts from a single fingerprint. Subscription renewals with expired cards produce failure spikes that have nothing to do with fraud. Before you block, confirm that the cluster spans multiple card numbers, not one customer retrying one card.
Why Timing Matters
Card testing windows are short. Attackers run their list, keep the live cards, and move on, often inside a few hours. A weekly fraud review will find the damage after the fact through chargebacks and network fees. Set an alert that fires on the velocity thresholds above so you catch the burst while it is still running. The earlier you cut off the source, the fewer cards get validated and the fewer chargebacks land on your merchant account.