Card Testing IoCs: Indicators of Compromise to Detect

Card testing indicators of compromise, or IoCs, are the signals left in payment and web logs when someone runs a list of stolen card numbers through a checkout form to learn which ones still authorize. The pattern is consistent: a burst of small authorization attempts, a heavy decline rate, a handful of approvals, and reuse of the same devices, IPs, or email addresses across many different cards. Detection comes from velocity, reuse, and failure ratios, not from any single transaction.

Prerequisites

• Access to raw gateway or processor authorization logs, including response codes and timestamps.
• Device, IP, and session identifiers tied to each attempt.
• A 30 to 90 day baseline of normal decline rates by card brand and BIN.

Signals in payment and web logs

• Many card numbers tried from one IP, device fingerprint, or session within minutes.
• Authorization amounts clustered at 0.00 to 1.00 USD, or repeated 1.00 pre-auth checks.
• Card numbers in sequential or near-sequential order within the same BIN range.
• CVV and AVS failures far above the account baseline, followed by sudden approvals.
• Decline codes dominated by do not honor, invalid card number, or incorrect CVV.
• Email addresses that change with every attempt, or one email tied to dozens of cards.
• Checkout sessions under a few seconds, or a form filled without cursor movement and keystroke events.
• Geo mismatch between IP, billing country, and card issuing country.
• Sharp spikes in 4xx responses from your payment API endpoint.

Sequence that separates card testing from ordinary declines

1. Sort authorization attempts by card fingerprint and by IP over a 24 hour window.
2. Count distinct card numbers per IP, device, and email.
3. Flag any group where distinct cards exceed five and the median ticket is under one dollar.
4. Check the decline-to-approval ratio inside each flagged group.
5. Look for one approval after ten or more declines on the same device.
6. Trace what happens to that approval: shipping address change, expedited delivery, or digital goods delivery.

Issuer and processor side signals

Issuers see the same event from the other direction: one merchant account drawing a large volume of low-value authorizations across many BINs, with a high proportion of invalid card numbers. Acquirers often flag this as a merchant risk item before the merchant notices. If your chargeback ratio starts to move alongside a rise in small-ticket approvals, treat the two as one event.

Validate before you block

1. Pull three examples of each flagged pattern and read the raw request data.
2. Confirm the attempts came from distinct cards, not one customer retrying a declined purchase.
3. Check whether the IP belongs to a hosting provider, proxy, or residential range.
4. Compare against the same hour on previous weeks to rule out a traffic spike.

Response steps

1. Enable rate limits per IP, device, and card fingerprint on the authorization endpoint.
2. Add a CAPTCHA or challenge step after repeated declines from one session.
3. Block the payment attempt, not the entire IP range, unless the range is a known hosting block.
4. Refund or void approved test charges and void the associated orders.
5. Report confirmed activity to your acquirer and to the card brands' fraud reporting channels.
6. Keep the flagged device and IP list for retroactive matching against later orders.