Card Testing Scenarios: How Attacks Look and How to Stop Them

What are card testing scenarios?

Card testing scenarios are the patterns attackers use to check whether stolen card numbers still work before they use them for larger purchases or pass them on. The shape is consistent: a burst of low-value charges, a decline rate that jumps above your normal baseline, and many different cards hitting one checkout page in a short window. Each scenario leaves its own trail in your transaction and device data.

card test checklists

The attacker wants information, not the product. A charge that goes through confirms the card is open. A specific decline code tells them why it failed, so they adjust and try again. That is why test orders stay small and why they almost never ship to a real customer.

related article

For a merchant, the cost lands in chargebacks, processor fines, and account risk. Card networks treat test traffic as a sign of weak controls at the point of sale.

Card Test Guidelines: A Comprehensive Buying Guide

Which card testing scenarios show up most often?

Most attacks reuse a small set of entry points. The five below cover the bulk of what fraud teams see in card-not-present environments.

1. Micro-charge trials on cheap items

Attackers target a $1 digital download or a small shipping fee. Low amounts slip under manual review thresholds and often skip cardholder alerts. A run of approved charges under $2 from one IP range is the clearest sign of a test.

2. Donation and tip pages

Charity, tip, and contact forms accept a card with almost no friction. There is no cart, no shipping address, and often no CAPTCHA. Fraud rings favor these pages because a rejection gives them the answer they want and costs them nothing.

3. Free trial and $0 authorization signups

A $0 or $1 authorization verifies a card without moving money. The attacker abandons the account once the check returns. Watch the ratio of signups to paid conversions by email domain and device fingerprint.

4. Distributed runs across proxies and devices

Residential proxy pools and headless browsers spread attempts so no single IP crosses a limit. The tell is the pattern across sessions: one card BIN range, one product, one narrow time band. Per-IP rules miss this; per-BIN and per-device limits catch it.

5. Verification probes against AVS and CVV

Some tests aim at the address and security code checks rather than the charge itself. Attackers submit the same card with different ZIP codes to learn which pairing passes. A cluster of declines on mismatched postal codes from one session is a probe, not a confused shopper.

Which signals give a card testing attack away?

No single signal proves an attack. Two or three together usually do.

• Decline rate on one endpoint that runs far above your baseline
• Several different cards tried from one device or IP inside a few minutes
• Average order value well below your normal range
• Repeated billing details paired with a rotating card number
• Card BINs from issuing banks you do not serve
• Traffic spikes at hours your customers do not shop
• Many accounts created from one email domain
• 3-D Secure challenges started and abandoned at a high rate

How is card testing different from friendly fraud?

Friendly fraud is a real customer disputing a real charge after delivery. Card testing is a stranger probing numbers that may not belong to anyone in your customer base. The two diverge on volume, order value, and shipping data.

Friendly fraud shows one normal purchase followed weeks later by a dispute. Card testing shows failed attempts stacked together, no delivery address or a fake one, and a device that never returns after the run ends.

How do you stop card testing?

1. Set velocity limits per IP, device, email, and card BIN, then tighten them for high-risk regions.
2. Require CVV and address verification on every card-not-present order, and block on a mismatch instead of flagging it for review.
3. Add CAPTCHA or a bot score to low-value checkout pages, donation forms, and trial signups.
4. Trigger 3-D Secure for new customers and for small charges from devices you have not seen.
5. Block repeated $1 authorizations from the same fingerprint, or raise your minimum order value on digital goods.
6. Watch decline codes in real time and block a device after a set number of failures in an hour.

Rules alone will not hold. Review the thresholds each month, because attackers learn your limits and adjust to sit just below them.

What should you do after an attack?

Move fast on the open authorizations. Void unsettled test charges before they clear, then block the IP range and device fingerprint tied to the run.

Contact your acquirer or payment processor and describe what happened. Processors see test traffic across many merchants and can flag related accounts. Review the endpoint that took the traffic and confirm that logging captured the request data you need for the next round.

Then check the approvals, not just the declines. Any test charge that settled can turn into a chargeback in 60 to 120 days, and those disputes count against you.

Frequently asked questions

Why do attackers test cards with small amounts?

A small charge draws less attention from the cardholder and often skips manual review. It still confirms that the card is open and that the security code matches.

Does CVV verification stop card testing?

Not by itself. Some stolen card records include the security code, so a CVV check narrows the pool without closing it. It works best when paired with velocity limits and device checks.

How long does a card testing attack last?

Most runs last from a few minutes to a few hours. A patient attacker spreads attempts over days to stay under rate limits, which is why trend reports matter more than single-hour alerts.

Can card testing hurt approval rates?

Yes. A high decline rate and a fraud flag raise your risk score with the acquirer, and that score follows the account across processors.

Do test orders ever turn into real losses?

Sometimes. Attackers occasionally place a normal-value order to confirm a card works for larger amounts. Those orders ship, and the chargeback arrives weeks later.

Keep a log of every blocked attempt. That record is how you spot the next run before it reaches checkout.