Card Test Rules Examples: How Merchants Detect Card Testing

Card test rules are the checks a payment system runs before an authorization is approved, and a common example is a velocity rule that blocks more than three declined attempts from one device within ten minutes. Those rules exist to stop card testing, the practice of running small or rapid charges to learn which stolen card numbers still work. The rules are written by merchants, fraud teams, and acquiring banks.

What counts as a card test rule

A card test rule is a condition that scores, blocks, or forces extra verification on a transaction. Rules differ from machine learning models because a person can read them, audit them, and change them in minutes. Most fraud stacks run both: rules for known patterns, models for everything else.

Rules usually return one of three outcomes:

• Block. The authorization never reaches the issuer.
• Review. The order is held for manual checks.
• Step-up. The customer must pass 3D Secure or another challenge.

Card test rule examples

These examples follow the structure condition + threshold + action, which is how most rule engines are built.

• Card velocity. Block when the same card number produces more than five authorization attempts in one hour.
• Device velocity. Block when one device fingerprint generates more than ten attempts in thirty minutes.
• Low amount trigger. Review any transaction under one dollar from a customer with no order history.
• AVS and CVV mismatch. Decline when both the address check and the security code check fail on a first order.
• Email reuse. Review accounts that attach four or more distinct cards to the same email address in a day.
• BIN clustering. Flag when several card numbers from the same issuer prefix appear within a short window.
• Geography mismatch. Step up when the issuing country, the IP country, and the billing country are three different places.
• Authorization ratio. Pause a merchant account when the decline rate passes 40 percent in an hour.
• Proxy and datacenter IPs. Block traffic from known VPN ranges when the order value sits below a set floor.
• Chargeback lookback. Block a card that has an unresolved chargeback on file.

Signals that feed the rules

Rules are only as useful as the data attached to each attempt. Inputs that show up in most rule sets include the device fingerprint, IP address and geolocation, card BIN, AVS and CVV response codes, email age, phone number, prior order history, issuer response codes, and the timing between attempts.

Timing matters more than many teams expect. A burst of attempts inside two minutes across several cards points to automation, while a slow trickle over days points to a different pattern.

Tuning thresholds without blocking good customers

Every threshold trades fraud loss against false declines. A practical process looks like this:

1. Run new rules in monitor mode and log what they would have caught.
2. Compare flagged attempts against confirmed fraud and genuine customer orders.
3. Tighten the threshold only where the fraud hit rate is clear.
4. Recheck after any pricing change, promotion, or new market launch.

Why these examples matter beyond fraud loss

Visa and Mastercard monitoring programs track authorization activity at the merchant and acquirer level. Heavy card testing can push an account into a monitoring program, add fees, and in serious cases remove the ability to accept cards. Chargeback ratios count too. Card test rules are therefore both a fraud control and a compliance control.

Common questions

Are card test rules the same as fraud rules?

Card test rules are a subset. Fraud rules cover a wider range of behavior, including account takeover and friendly fraud, while card test rules focus on repeated authorization attempts that probe whether a card is live.

How often should rule examples be reviewed?

Review the set at least monthly, and again after any spike in declines, chargebacks, or issuer error codes. A rule that fit last quarter may not fit this one.