What are card testing rules?

Card testing rules are the fraud controls a merchant or payment processor applies to spot and block the small, rapid charges used to check whether stolen card numbers still work. A complete rule set combines velocity limits, amount thresholds, BIN and geography filters, device signals, and CVV or AVS checks.

In practice, card testing shows up as a burst of low-value authorizations from one IP range, device, or email pattern, with each attempt using a different card number.

Why card testing costs more than the stolen charges

The individual charge is often under a dollar, so the direct loss looks small. The real cost lands on dispute fees, network monitoring programs, and processor penalties that follow a spike in unauthorized transactions.

• Chargeback fees per disputed transaction, which can exceed the original amount by a wide margin.
• Excess dispute thresholds that trigger network fraud monitoring programs.
• Higher processing rates or account termination when the fraud ratio stays high.
• Stolen inventory when a validated card is later used for a large fraudulent order.

How a card testing run looks in your logs

Card testing needs a way to submit many payments in a short window. Attackers target donation pages, guest checkout, gift card purchases, and free-trial signups because those flows skip account creation.

The first attempts often come from a single BIN (bank identification number). Once a card returns an approval, the attacker moves to a larger purchase with the same number.

Merchants see three signals in the data: repeated declines, shared or sequential email addresses, and a gap between the IP country and the billing country.

The core rule categories

Velocity rules

• Card attempts per IP address per hour.
• Attempts per device fingerprint or browser cookie.
• Distinct card numbers per customer session or per email address.
• New accounts created from one IP in a 24-hour window.

Amount and sequence rules

• Flag any authorization under $1 or $2 followed by a larger charge from the same identity.
• Block repeated identical amounts from one device.
• Cap the number of authorizations allowed per session.
• Watch for round-dollar test amounts of $0.00 or $1.00.

BIN, country, and geography rules

• Send orders to review when the IP country and billing country differ.
• Watch cards issued outside your normal market.
• Flag bulk traffic from one BIN inside a short window.

CVV, AVS, and authentication rules

• Decline on CVV mismatch for physical goods and digital goods alike.
• Decline on AVS mismatch for orders above a set value.
• Request 3D Secure when the risk score crosses a threshold, since authentication shifts chargeback liability to the issuer.

Device and network signals

• One device fingerprint tied to many card numbers.
• Datacenter, proxy, or VPN IP ranges instead of residential connections.
• Headless browser traffic with missing headers or no referrer.

Prebuilt rule sets vs custom rules

Most processors ship default rule sets that cover known card testing patterns. Custom rules matter when your traffic profile differs from the average merchant in your category.

Turn the defaults on first, then write new rules from what you see in your own decline logs. Duplicating a default rule with a tighter threshold rarely adds coverage and increases false declines.

How to set rules without blocking real customers

1. Baseline your traffic. Record normal authorization volume per IP, device, and hour before you pick a threshold.
2. Start in monitor mode. Log matches for a week and measure false positives before you block anything.
3. Stack signals. One signal is noise; three agreeing signals are a case.
4. Use a review queue. Send borderline matches to manual review instead of a hard decline.
5. Review the rule set each month. Card testing tactics shift, so last quarter's thresholds may miss this quarter's attack.

Where the rules fire in the payment flow

Rules can run before authorization, during authorization, or after. Each stage carries a different cost when the rule fires.

• Pre-auth: a block costs nothing at the processor and stops the attempt early, but it risks turning away a real buyer.
• During auth: a decline reaches the issuer and counts toward your decline ratio, so save it for clear matches.
• Post-auth: void before capture or refund the charge. Slower and it costs interchange, but customers never notice.

What card network rules require

Visa and Mastercard both run fraud monitoring programs that push acquirers to control card testing. Merchants whose fraud-to-sales ratio crosses a set threshold enter a monitoring cycle, and repeated breaches can lead to fines or lost processing rights.

Exact thresholds differ by network, region, and merchant category, and they change over time. Ask your acquirer for the current numbers instead of relying on a figure from an older guide.

Common mistakes

• Blocking all foreign IPs, which removes legitimate cross-border sales.
• Setting velocity limits so tight that repeat customers trip them.
• Watching card numbers while ignoring device and email velocity.
• Leaving guest checkout and donation forms without a CAPTCHA or rate limit.
• Ignoring decline codes. A flood of "do not honor" responses points to card testing, not a payment outage.

FAQ

Are card testing rules the same as fraud rules?

Card testing rules are a subset. They target the small, rapid authorizations used to validate cards, while general fraud rules cover account takeover, refund abuse, and resale of stolen goods.

What is a BIN attack?

A BIN attack is a card testing run that guesses valid card numbers inside one bank identification number. It depends on merchants that do not rate limit authorization attempts.

Do these rules apply to digital goods?

Yes. Gift cards, software keys, and subscriptions are common targets because delivery is instant and there is no shipping address to verify.

What fraud ratio triggers network monitoring?

Thresholds vary by network and merchant size, and they get revised. Your acquirer or payment processor can give you the figure that applies to your account.

Bottom line

Card testing rules work when they combine several weak signals into one strong decision. Velocity, amount, BIN, geography, device, and CVV checks together catch far more attacks than any single limit.