Fraud detection card test protocols are the checks that issuers and merchants apply to small, low-value authorization attempts to separate a real customer from someone validating a stolen card number. Issuer-side checks cover CVV match, address verification, expiry date, and account status. Merchant-side checks cover velocity, device and IP reuse, BIN concentration, and decline rates across many attempts.

more on this topic

This guide covers the detection side. Testing a card you do not own is a crime in the US under access device fraud statutes, and the material below is written for risk teams defending a store.

more on this topic

What signals does a card test leave behind?

One small authorization tells you almost nothing. The pattern across hundreds of attempts does.

fraud detection card test methods

• Card velocity per device: many different card numbers tried from one browser fingerprint or one app install.
• Card velocity per IP or subnet: dozens of attempts from one address, or a rotating set inside a single /24 block.
• Sequential numbers: PANs that climb by small increments point to generated numbers, not stolen ones.
• BIN clustering: attempts spread over a narrow set of issuing banks, or over BINs tied to prepaid and virtual cards.
• Decline ratio: an account running 60 to 90 percent declines on small tickets is being probed.
• Geo mismatch: IP country, billing country, and issuing bank country that do not line up.
• Channel choice: donation widgets, free trials, $1 verification holds, and gift card balance checks attract tests because the amounts are tiny.

How do issuers answer a test authorization?

The issuer returns a response that says whether the card is live and whether the security data matched. Testers read those responses the same way a legitimate merchant does.

fraud detection card test protocols

• CVV match or no match: confirms whether the three-digit code on the back is correct.
• AVS result codes: street and ZIP match, ZIP only, no match, or address unavailable.
• Do not honor: a generic decline. It can mean a closed account, a block, or a risk rule on the issuer side.
• Pick up card: a hard block, often triggered when the account is already flagged as stolen.
• Invalid account or expired card: the number or expiry failed a check digit or a date test.

An approval on a $1 authorization proves the card is open. It does not prove the person holding the number is the cardholder. That gap is where merchant-side detection has to work.

Where do network rules fit in?

Card networks publish rules that let acquirers fine merchants with high fraud and chargeback ratios. Test traffic inflates both numbers even when the dollar amounts are small. A merchant that ignores a testing wave can lose the account before the chargebacks settle.

Processors also watch the ratio of authorizations to settlements. A ratio far from the norm on low-ticket transactions reads as probing, and some processors freeze the account on that signal alone.

Which detection rules catch card testing fastest?

Rules that count attempts and compare them to a baseline beat rules that try to score each order alone.

1. Velocity caps per identifier. Set limits on attempts per card, per device, per IP, per email, and per shipping address inside a rolling window.
2. Minimum ticket on risky channels. A floor of a few dollars blocks most $0 to $1 probes while leaving real donors and trial signups alone.
3. Device fingerprinting. Group attempts by browser, canvas hash, and installed fonts, not just by IP, because proxies rotate faster than devices do.
4. Decline-rate monitoring. Alert when authorization attempts rise while settled volume stays flat.
5. Step-up authentication. Push suspicious sessions into 3-D Secure so the issuer runs its own check before the charge lands.
6. BIN and country rules. Block or review cards issued in countries you do not ship to, and flag prepaid BINs on high-risk channels.
7. Proxy and hosting detection. Most test traffic arrives from data center IP ranges, VPN exits, and residential proxy pools.

Why do attackers target donation pages and free trials?

Those flows take tiny amounts and often skip full address and CVV enforcement. A donation form that accepts $1 with no AVS match is a cheap way to check a batch of numbers. Free trials and $0 authorization holds do the same job for subscription merchants.

The cost to the attacker is one request per card. The cost to the merchant is a pile of chargebacks, network fines, and a processor that starts asking questions. That asymmetry is why these attacks escalate once a soft target is found.

What should a merchant do during an active attack?

1. Throttle, do not just decline. Rate limits on the endpoint cut the volume without teaching the attacker which rule fired.
2. Add a challenge. CAPTCHA or a device check on the test-prone flow raises the cost per attempt.
3. Raise the floor. Set a minimum amount and require CVV plus AVS on small tickets.
4. Block the infrastructure. Deny the ASNs and proxy ranges in the current wave, then review the list once a week.
5. Log everything. Keep raw request data, response codes, and timestamps for the processor and for law enforcement.
6. Report it. File with the FBI Internet Crime Complaint Center and notify your acquirer the same day.

Frequently asked questions

Is card testing the same as carding?

Carding is the wider trade in stolen card data. Card testing is the verification step inside it. A tester checks whether a number, expiry, and CVV are still valid before the data is sold or used for a larger purchase.

Does a CVV mismatch always mean fraud?

No. Typos, stored cards with old data, and card reissues all produce mismatches. A mismatch matters when it repeats across many cards from one device or one IP range.

Is card testing illegal?

Yes. In the US, using card data you are not authorized to use falls under access device fraud, 18 U.S.C. § 1029, and related wire fraud charges. Merchants that look the other way can face processor penalties and civil liability.

How fast can an attack scale?

A single script can push thousands of authorization requests per hour against an unprotected endpoint. Volume, not sophistication, is the usual giveaway.

Do I need a fraud vendor to detect this?

Not at first. Velocity limits, a minimum ticket, and CVV plus AVS enforcement stop most probes. A vendor helps once you need shared device and BIN intelligence across merchants.