Card testing rules are the specific thresholds and conditions a payment stack enforces to catch a run of small authorization attempts before those attempts turn into chargebacks. They are not one document. They sit in three layers: the gateway's fraud engine, the acquirer or processor's risk settings, and the card networks' velocity and fraud programs. Each layer looks at different signals and each one can decline, block, or step up a transaction on its own.
question what are the card testing rules?
What the rules actually check
I look at a card testing rule as a small conditional statement: if these conditions are true within this window, do this. The conditions cluster around a handful of signals.
- Velocity per card. Attempts on the same PAN inside a rolling window. Three to five authorization tries in an hour on a card that has no history is a common trip point.
- Velocity per IP, device, or email. Ten or more distinct cards attempted from one address in ten minutes is the pattern most engines flag first, because real shoppers rarely rotate cards.
- Amount shape. Many small authorizations, often under one dollar or just above a merchant's minimum, clustered together. Fraud engines score the distribution, not just the size.
- Verification mismatch. AVS fail combined with CVV fail on the same attempt, or a mismatch on a card that previously passed.
- BIN and geography spread. A single session touching many issuing banks or countries in sequence.
- Retry behavior. Rapid resubmission after a decline, especially with a changed amount or a changed address field.
Where the rules live
The gateway layer is the most tunable. Most fraud engines let a merchant write custom rules on top of a default ruleset, and the defaults are conservative: block on repeated CVV failure, flag on card velocity, hold for review on mismatched billing country. The processor layer is broader and less visible to the merchant. Acquirers set monthly and daily velocity caps on merchant accounts and will freeze an account that shows a spike in tiny authorizations with no matching settlement volume. The network layer is the widest, and it is where the programs that monitor merchant-level fraud ratios live. Issuers run their own rules too, which is why one card declines at the gateway while another sails through the exact same request.
Synonym Card Verification Guidelines
The response ladder
Rules do not only block. A well-built stack has a graded response.
synonym card verification guidelines
- Soft decline with a reason code, so the merchant can decide whether to retry.
- Step-up authentication, sending the attempt to 3-D Secure for issuer-side verification.
- Hard block on the card, device, or IP for a set period.
- Manual review queue, where a human checks order history and contact details.
- Account-level action, up to suspension of the merchant account.
The order matters. Blocks placed too early cost real sales from customers who mistyped a digit. Blocks placed too late let a testing run finish and the chargebacks arrive six weeks later.
Tuning against false positives
Every velocity rule has a legitimate counterpart. Gift card resellers, subscription renewal retries, and corporate purchasing cards all produce bursts that look like testing. I check whether the decline rate on a new rule is concentrated in a small set of SKUs or price points, and whether the flagged attempts ever convert after a retry. A rule that catches testing but also kills 5 percent of clean checkouts needs a narrower condition, not a higher threshold. The usual fix is to require two signals to fire together, such as card velocity plus a CVV mismatch, rather than either one alone.
What gets missed
The gap I see most often is a rule that watches cards but not the checkout session. Testers rotate cards and IPs but reuse the same browser fingerprint, the same email pattern, or the same shipping address shape. Pairing a device-level rule with a card-level rule catches far more than either alone, and it does it without raising friction on ordinary buyers.