Card Testing Examples: Patterns in Authorization Logs

What card testing is

Card testing is a fraud step. Someone holds a list of card numbers and needs to know which numbers still authorize. The check is a real authorization request, sent at a low amount. Numbers that approve move to a cash-out step. The merchant that approved the test absorbs the chargeback and the interchange fee.

Card Test Specifications Guide

The examples below come from merchant authorization logs. They describe patterns, not tools.

Card Test Checklists: What to Verify Before You Ship a Payment Flow

Example 1: Low-value authorization bursts

One IP address sends 40 to 200 authorization requests in under 10 minutes. Amounts sit between $0.00 and $1.00. Approval rate lands near 5 percent. Declines cluster on the reason code "do not honor." One approval follows the burst. That approval is the number the attacker keeps.

Card Test Guidelines: A Comprehensive Buying Guide

Example 2: BIN runs with sequential numbers

Requests share the first six digits and differ in the last four, which increment. A run of 500 numbers takes minutes on a scripted client. Expiration dates repeat across the run. Cardholder names repeat, or arrive as "test test" or a single letter.

Example 3: AVS and CVV mismatch

Billing ZIP codes fail the Address Verification System check on most attempts. The CVV response returns a mismatch on 70 percent or more of requests. IP geolocation does not match the card's issuing country. A valid card number paired with a wrong CVV still returns a distinct response code, and that code is what the test reads.

Example 4: Trial signups and donation forms

Attackers pick endpoints with a $0 or $1 authorization and no 3D Secure step. Free-trial signups, donation widgets and digital gift card pages are common targets. Each approval confirms a live card. Each approval also creates an account the attacker can reuse.

Example 5: Distributed volume

Volume per IP stays at 2 to 5 requests. Traffic spreads across hundreds of IP addresses and many email domains. Device fingerprints rotate. Velocity rules keyed to a single IP miss the pattern. Velocity rules keyed to a BIN catch it.

Example 6: Test, then cash out

A tested card shows one $1 approval. Minutes later the same card number buys $400 to $900 of resellable goods at a different merchant: gift cards, prepaid codes, electronics. The gap between test and cash-out is short.

Signals in the authorization log

• Decline rate above 80 percent on one BIN in a short window.
• Median ticket size under $1.
• CVV mismatch rate above 50 percent.
• One device fingerprint across many card numbers.
• Many card numbers, one email domain.
• Authorization attempts at round dollar amounts under $2.

Controls that stop it

• Enforce CVV and AVS. Treat a mismatch as a decline, not a warning.
• Set velocity limits per BIN, per IP, per device and per email.
• Apply 3D Secure to first-time and low-value card-not-present transactions.
• Disable $0 and $1 authorizations on endpoints that do not need them.
• Review issuer decline reason codes. A run of "do not honor" on one BIN is a signal.
• Log the full authorization response, not just the approval flag.

What the log does not show

Authorization data does not identify the person behind the request. It shows a pattern. A decline spike can also come from an issuer outage or a pricing error. Confirm the pattern across two or more signals before blocking a BIN range.

Reporting

US merchants report card testing losses to their acquirer and to the Federal Trade Commission. Issuers also want the BIN range and the timestamps. Keep the raw authorization records for the chargeback window, which runs 120 to 180 days on most card networks.