Card testing IoCs, or indicators of compromise, are the observable signals left behind when someone uses a checkout page to check whether stolen card numbers are valid. They usually appear as a burst of small or zero-value authorization attempts, a sharp rise in declines, and many different card numbers arriving from the same IP address, device, or email pattern. Catching those signals early is what keeps a card testing run from turning into a wave of chargebacks and processor penalties.
What card testing is, in one paragraph
In a card testing attack, also called a carding or BIN attack, an automated script submits payment details against a merchant's payment endpoint. The attacker is not trying to buy anything. Each attempt is a probe: an approved charge means the card number, expiry, and often the CVV are valid and can be resold or used elsewhere. Merchants are targeted because their payment page is a cheap, fast place to validate a large list of numbers. The attack is over quickly, so the evidence lives in your logs rather than in your order queue.
Card Testing IOC List: A Comprehensive Guide
Payment-level indicators
These show up in gateway and authorization records, so they are usually the first thing an analyst notices.
how to use iocs for card testing
- A cluster of authorizations for very small amounts, frequently under a few dollars, across many unrelated card numbers.
- A decline rate that jumps well above the normal baseline for the store in a short window.
- Long runs of the same decline reason, such as insufficient funds, do not honor, or invalid card number, repeating in sequence.
- Many cards sharing one billing ZIP, one email address, or one customer record.
- Card numbers that fall into a narrow BIN range, which points to a single purchased card list.
- Authorization attempts that never produce a completed order, with carts abandoned right after a payment attempt.
Traffic and device indicators
Card testing IoCs are not only about payments. The request pattern around the payment endpoint is often more telling than the transaction itself.
- Machine-speed submit intervals, with gaps of a few milliseconds or a few seconds that do not vary like human input.
- Many sessions from one IP address or one narrow IP block, especially data center, VPN, proxy, or Tor exit addresses.
- Direct POST requests to the payment or checkout endpoint without the page views, script loads, or cart steps that a real shopper generates.
- Repeated identical device fingerprints, or fingerprints that lack the usual browser attributes and canvas or JavaScript output.
- Outdated or mismatched user agents, headless browser signatures, and missing or malformed referrer headers.
- Geographic mismatches between the IP country, the billing country, and the card's issuing country.
- Requests that ignore cookies, fail to load images or CSS, and never touch any page besides checkout.
Customer-data indicators
The details attached to the attempts often reveal automation as clearly as the traffic does.
- Email addresses on disposable domains, or patterns such as name plus a number plus a domain, generated at volume.
- Plus-addressing used to create many variations of the same mailbox in a short period.
- Names, addresses, and phone numbers that repeat across unrelated card numbers.
- Newly created accounts that place a payment attempt within seconds of registration.
Where to collect these signals
No single log holds the full picture, so correlate a few sources before you conclude an attack is underway.
- Payment gateway records: amounts, approval and decline responses, and timestamps down to the second.
- Web server and WAF logs: request paths, status codes, user agents, and source IPs.
- Application database: account creation times, cart activity, and order history.
- Chargeback and dispute reports, which may confirm an attack that looked small at the time.
- Bot management or CDN telemetry, including request rate by IP and by ASN.
How to respond when IoCs appear
Treat a confirmed card testing run as an incident with a short playbook.
- Rate limit or temporarily block the source IPs, ASNs, and device fingerprints involved.
- Add velocity rules that cap payment attempts per card, per email, per device, and per IP over a rolling window.
- Require a challenge such as a CAPTCHA or a verified session token before the payment step.
- Enforce 3D Secure or strong customer authentication where your market and processor allow it, since it shifts liability and stops most automated probing.
- Alert your acquiring bank and payment processor with the evidence you collected.
- Refund or void any micro-authorizations that captured funds, and review accounts created during the window.
- Add the confirmed indicators to a blocklist and monitor for the pattern returning from new infrastructure.
False positives to rule out
Some legitimate activity looks like card testing and will cost you sales if you block it. Subscription retries, card-on-file verification, and zero-value authorization checks from returning customers all produce small transaction bursts. Gift card balance checks and address verification tests can also mimic the pattern. Compare against your normal baseline before you tighten rules, and keep a review step for anything that only partially matches the list above.
Keeping the indicators useful
Card testing IoCs change as attackers rotate infrastructure, so a static list ages quickly. Review your detection rules against recent traffic, track which signals actually preceded real fraud at your store, and drop the ones that only produce noise. The goal is not to catch every automation attempt. It is to make probing your payment page slow, expensive, and unproductive enough that the next script moves on.