A card testing detection system watches your checkout for the signature of someone running a list of card numbers to learn which ones still authorize. It is not a single rule. It is a stack of signals scored together: authorization responses, request velocity, device and IP reputation, and the shape of the traffic before and after the payment step. The goal is simple. Catch the run in seconds, not in a chargeback report six weeks later.
Why the pattern is easy to describe and hard to catch
Card testing looks like normal shopping if you only look at one request. A single $1.00 authorization from a residential IP with a real browser is not suspicious. The tell is in the aggregate. Attackers work from proxy pools, hit the payment endpoint directly, and abandon the cart the moment the response comes back. Thousands of those requests together read like a machine, even when each one looks clean.
card testing detection software
Signals I weight most
- Authorization response mix. A burst of declines with a few approvals is the classic fingerprint. So is a spike in specific decline codes tied to invalid account numbers.
- Velocity per dimension. Count attempts per card, per IP, per device fingerprint, per email, and per shipping address. Attackers rotate one and forget another.
- Endpoint behavior. Direct POSTs to the payment API, missing session cookies, and no product page views before checkout all point the same direction.
- Amount clustering. Many attempts at the same tiny amount, or amounts that increment by a cent, are a script, not a shopper.
- IP and ASN reputation. Datacenter ranges, known proxy services, and high-risk geographies raise the score fast.
- Email and phone reuse. Disposable domains and sequential numeric addresses rarely come from real buyers.
Building the rule layer first
Start with deterministic rules because they are cheap and explainable. Set an attempt ceiling per card, IP, and device over a rolling window. Add a second ceiling on failed authorizations per hour across the whole store. Require a CAPTCHA or a step-up challenge when any counter crosses its threshold, and block outright at a higher one. Log every decision with the reason attached so you can answer "why was this customer declined" without guessing.
Where scoring beats static thresholds
Rules alone either fire too often or too late. A scoring model blends dozens of weak signals into one risk number, which lets you take graduated action: allow, challenge, review, block. Train it on your own authorization and chargeback history rather than a generic feed. Fraud patterns shift by merchant category. What flags a digital goods store will not flag a furniture retailer.
Response playbook
- Throttle the source and force a challenge on the next request from that device or IP.
- Void or refund authorizations tied to the suspected run before capture.
- Alert the acquiring bank and, if card data was exposed elsewhere, the affected issuers.
- Review the log to find the entry point the run used and close it.
- Keep the block in place for a cooling period, then re-test the rule against live traffic.
What to measure
Track detection latency, false positive rate, blocked attempt volume, and the chargeback count from card testing specifically. A system that blocks a lot but also declines good customers is not working. I would rather see a modest block number with a low false positive rate and a falling dispute ratio than an aggressive filter that scares off repeat buyers.