Card Test Decline Rate, Explained Plainly
Card test decline rate is the percentage of card-testing authorization attempts against your checkout that the issuer rejects. During an active attack it usually runs high, often well above 60%, because whoever is running the script is cycling through numbers that may be dead, blocked, or already reported by the real cardholder. For you, that high number is the alarm bell. It is not a gateway fault, and it is not a reason to loosen your fraud rules.
The raw figure matters less than what sits behind it. Look for many attempts, small ticket sizes, one or two cards per IP address, and a decline spike that appears within minutes rather than over a week.
Why Card Testing Generates So Many Declines
A person running a card-testing script does not know which numbers are live. That is the whole point of the exercise. They fire off a batch of low-dollar authorizations and let the responses sort the pile. Roughly half to nine-tenths of those attempts get declined, which means your decline rate climbs even though your approval rate on real customers has not moved.
Issuer-side rules do most of the work here. Velocity caps, mismatched CVV or AVS responses, and geolocation checks all push traffic toward a decline. Attackers respond by spreading attempts across many BINs and many IPs, which is exactly why a single-metric view of decline rate will mislead you.
Merchant Decline Rate Is Not Issuer Approval Rate
These two numbers get conflated constantly. Your decline rate counts everything your processor and the issuer turned down, including the junk traffic. Issuer approval rate counts only the transactions that reached a decision. When card testing floods your payment page, decline rate spikes while approval rate on genuine orders stays flat or dips slightly. If both move together, you probably have a real approval problem rather than an attack.
Signals Worth Tracking Alongside the Number
- Attempts per IP address and per card over a rolling hour
- Ticket size distribution, since testing clusters at the lowest allowed amount
- Decline reason codes, split by issuer response category
- BIN concentration, because a narrow BIN range points to a single batch
- Time-of-day skew compared with your normal customer curve
What Brings the Rate Down
You are not trying to fix the decline rate. You are trying to remove the traffic causing it. Rate limits on authorization attempts per session and per IP do the heaviest lifting. Requiring CVV verification, tightening AVS rules, and enabling 3D Secure on high-risk segments all raise the cost of each guess. Blocklists and velocity rules should be tuned from your own decline logs, not copied from a forum post.
I would also watch small authorizations from new accounts with mismatched billing details. Those rarely convert into real revenue, so treating them as suspicious costs you almost nothing.
Set a Baseline Before You Need One
A decline rate only means something against a baseline. Track it daily by channel, device type, and new-versus-returning customer. Once you know your normal range, a jump of ten points in an hour tells you something is happening. Without that baseline, you will spend the spike arguing with your processor instead of shutting the attack down.