Card Testing IoCs: How to Spot and Stop the Attack

Card testing IoCs are the log signals that show someone is running stolen card numbers through your checkout. The core markers are many small authorizations in a short window, high decline rates from one IP or device, and card numbers that arrive in sequence. Catching them early stops chargeback fees, processor penalties, and lost revenue.

What is card testing?

Card testing is a fraud attack where someone pushes a list of stolen card numbers through a payment form to learn which ones still work. The attacker does not want the goods. The goal is a clean list of live cards to resell or reuse.

Because the attacker only needs a yes or no answer from the processor, the orders stay small. Many runs use the cheapest item on the site, a donation field, or a $1 amount on a single SKU.

What are the most common card testing indicators of compromise?

Card testing IoCs come in two layers: signals inside the transaction data and signals inside the traffic that produced it. You need both to see the whole attack.

Transaction-level IoCs

• A burst of authorizations in a short window, from a few dozen to several hundred.
• Many different card numbers tied to one customer account, email, or shipping address.
• Card numbers that climb in sequence, such as 4000...0001, 4000...0002, 4000...0003.
• Repeat totals like $0.99 or $1.00, often on the same product.
• Very high decline rates on one account, with a handful of approvals mixed in.
• Card BINs from banks or countries that do not match your normal buyer base.
• CVV or AVS mismatch replies that cluster on a single account over minutes.
• Multiple orders shipped to one address but paid with unrelated cards.

Traffic-level IoCs

• One IP address or subnet sending far more checkout requests than normal.
• Missing or repeated browser headers, or a user agent that does not match the device.
• Accounts created minutes before the first payment attempt.
• No page views before checkout. Real shoppers browse. Testers go straight to pay.
• Requests spaced at machine-like intervals, with the same gap between each attempt.
• A single device fingerprint tied to dozens of card numbers.
• Traffic that ignores your robots rules and skips your cart page.

How do you tell card testing apart from normal decline noise?

Normal declines spread out. They come from returning customers, expired cards, and mistyped numbers. A card testing run looks like a spike with a shape: sudden start, tight timing, one entry point, one payload.

Pull the last 24 hours of failed authorizations and group them by IP, email, device ID, and card BIN. If one value appears across dozens of attempts, that value is your IoC.

Compare attempts to completed orders. A buyer who fails once may retry with another card. Fifty attempts from one session is not a shopper.

Which decline responses carry the strongest signal?

Issuer responses are the most direct evidence. Look for patterns of do not honor, pick up card, and insufficient funds replies arriving in bulk from one source.

Watch the mix. A run that returns two approvals out of sixty attempts tells the attacker the list is partly live, and that is exactly the run you want to cut off before it moves to larger amounts.

Authorization logs also show the timing. Real cardholders retry after a pause. Automated tools retry in seconds.

What should you do when you find card testing IoCs?

1. Rate limit the checkout endpoint. Cap attempts per IP, per session, and per card in a rolling hour.
2. Block what you confirmed. Add the IPs, device IDs, email patterns, and BINs from your log review to your deny list.
3. Add friction only where risk is high. Trigger a CAPTCHA or 3D Secure challenge on high-risk sessions instead of every order.
4. Void suspect orders. Cancel the small authorizations and refund any real cardholder who was charged.
5. Tell your acquirer and gateway. Many fraud desks can block BIN ranges and review fees tied to a confirmed testing run.
6. Watch for a second wave. Attackers often return to the same endpoint with a new list.

Can you stop card testing with CVV checks alone?

No. A CVV check rejects some stolen numbers, but automated lists often include the security code, so mismatches are not guaranteed. CVV checks work as one layer, not as a defense by themselves.

Stack controls instead: velocity limits, device fingerprinting, address verification, 3D Secure, and bot detection on the payment endpoint. Each layer raises the cost of a run and shortens it.

Frequently asked questions about card testing IoCs

How fast does a card testing attack run?

A small run can finish in minutes. Large runs stretch over hours and blend into normal traffic unless you count attempts by source. Speed is one reason manual review alone misses them.

Are card testing IoCs the same as account takeover IoCs?

They overlap. Both show bursts from few sources, new accounts, and odd headers. Account takeover adds password resets, login spikes, and saved-card changes that card testing does not have.

Where should you log card testing IoCs?

Keep failed authorizations, gateway responses, request headers, and device IDs in one place for at least 90 days. Fraud teams and processors ask for that window when a dispute or fee review starts.

Is a card testing spike a sign of a data breach on your site?

Not always. Most attacks use card lists bought elsewhere and target your payment form because it is public. That said, check for a breach if the tested cards match customer records you store.