Card Testing Guidelines: Detect and Stop Card Testing

Card testing guidelines are the rules a merchant writes down to catch one specific pattern: someone pushing a stack of card numbers through a checkout page in a hurry to learn which ones still work. The signal is rarely a big order. It is a flood of tiny ones. When your gateway shows a burst of $0.50 to $3.00 authorizations, a wall of declines from a narrow set of IP addresses, and a conversion rate that falls off a cliff for twenty minutes, you are likely being tested. The guidelines exist so you catch it in minutes rather than at month end when the chargebacks arrive.

What the attack actually looks like

I look for shape more than size. A single fraudster working through a purchased list leaves a fingerprint on your logs even when each individual request looks ordinary.

• Many cards, few customers. Dozens of BINs hitting the same checkout within a short window, often with no browsing history on the site.
• Small amounts first. Testers favor low dollar values because a declined $1 charge is cheap and a successful one proves the number is live.
• Decline rates that spike and then recover. Real shoppers do not generate fourteen consecutive do not honor responses.
• Mismatch between billing country, IP location, and shipping address. One of those being off is normal. All three disagreeing is not.
• Bots behind the traffic. Missing browser headers, instant form fills, and identical user agents across many sessions.

Why a written policy beats good instincts

Card testing costs you in three places at once: processing fees on authorizations that never turn into revenue, chargebacks with their associated fees, and monitoring program thresholds set by the card networks. Repeated testing on your account can also get you flagged as high risk by your acquirer, which raises your rates long after the attack ends. A short written policy keeps the response consistent when it happens at 2 a.m. on a Saturday and nobody senior is awake.

The guidelines I would put in writing

Velocity and shape limits

• Cap attempts per IP address, per device fingerprint, and per email domain over rolling windows of one minute, ten minutes, and one hour.
• Block or challenge after a set number of declines from the same source, not after a set number of successes.
• Flag any account that submits more than a handful of distinct card numbers in a session.

Make the card prove itself

• Require CVV and AVS on every card-not-present transaction, and treat a CVV mismatch as a hard stop rather than a soft warning.
• Turn on 3-D Secure for high-risk segments. Friction is cheaper than a fraud loss.
• Add a challenge that costs humans little and bots a lot, especially on guest checkout and account creation.
• Refuse multiple card attempts on one order. A real customer with a declined card will usually come back with one different number.

Keep the plumbing honest

Rate limiting belongs at the edge, not just in application code, and it should apply to your payment API endpoints as well as your storefront. Log the full request context for every authorization attempt so you can reconstruct an attack later. Store cardholder data only where PCI DSS requires it, and never in application logs.

Thresholds, monitoring, and the response

Pick numbers you can defend and revisit them monthly. Watch authorization volume against a rolling baseline, not against yesterday. When a burst hits: raise the velocity limits, enable the challenge on the affected endpoints, notify your processor's fraud desk with timestamps and source identifiers, refund or void what you can before settlement, and dispute chargebacks with the logs in hand. Then write down what you missed.

Working with your processor

Ask your acquirer which tools they offer for free before you buy a third-party fraud suite. Most gateways include velocity rules and blocklists that cover the common cases. The rest is discipline: a short document, a named owner, and a review after every incident.