The top pick for most merchants is a layered velocity rule set: real-time counters on card number, BIN, IP address, device, and customer account, evaluated before the authorization request leaves your system. It wins on four criteria: coverage of the card-testing pattern, decision latency at checkout, false-positive cost on legitimate buyers, and how fast the fraud team can tune rules and work the review queue.

What card testing looks like in authorization logs

Card testing is a scripted search for live card numbers. The attacker holds a batch of stolen PANs and needs to learn which ones still authorize, so the traffic leaves a signature: many distinct cards touched by one IP or device in a short window, small or repeated authorization amounts, a high share of declines, and card numbers that run in sequence or share a BIN. The goal is discovery rather than purchase, so attempts per card stay low while attempts per source climb.

That asymmetry is what a velocity engine measures. One card seen twice in a day is ordinary. Four hundred distinct cards from one address in an hour is not.

• Distinct card numbers per IP, device, or email in a rolling window.
• Authorization attempts per card across storefronts, channels, or stored profiles.
• Decline ratio per source, especially issuer responses for invalid card or CVV mismatch.
• Sequential or near-sequential PANs and repeated BINs from one source.
• Small ticket sizes, including $0 and $1 verification attempts.

Criterion 1: Coverage across card, BIN, IP, device, and account

Each dimension catches a different shape of attack. A card counter catches one PAN sprayed across many sources. A BIN counter catches batch attacks drawn from a single issuer range. Device fingerprints survive IP rotation, which residential proxy pools make cheap. Account and customer ID counters catch a repeat abuser who keeps returning with new cards.

Pros

• Runs on data already present in the authorization request, so no new vendor is required to start.
• Catches both fan-in (many cards from one source) and fan-out (one card across many sources).
• BIN and device counters keep working after attackers rotate IP addresses.

Cons

• Card-only counters miss testing spread thin across thousands of PANs.
• IP counters penalize corporate NAT, campus networks, and carrier-grade NAT traffic.
• Counters held per storefront undercount when the same buyer or attacker hits several channels.

Use case: a single-storefront ecommerce operation on one payment processor should start with card, BIN, IP, and device counters on both one-hour and twenty-four-hour windows, sharing counter state across every checkout endpoint it operates.

Criterion 2: Latency and placement in the payment flow

Velocity decisions belong before the authorization request, in the same call path as your payment orchestration. Counters kept in an in-memory store with short time-to-live values return in single-digit milliseconds, which keeps the whole check inside a typical 100 ms decision budget. Placing it earlier avoids sending obvious junk traffic to the processor at all.

Pros

• Blocking before authorization avoids interchange and per-request fees on traffic you already know is bad.
• In-memory counters scale to high request volume without touching the primary database.
• Works with zero-dollar verification and pre-authorization flows as well as standard sales.

Cons

• Retries and customer refreshes inflate counts unless requests carry idempotency keys.
• Counter store outages force a policy choice between failing open and failing closed, and both carry cost.
• Distributed checkout stacks can double count if the same event is written from more than one service.

Use case: a high-volume merchant with a microservice checkout should evaluate velocity once at authorization and re-check at capture, with a documented fail-open policy and alerting on counter store latency.

Criterion 3: Threshold tuning and false-positive control

Set starting thresholds from your own history rather than copying published numbers. Pull thirty to ninety days of authorization data, compute the distribution of each counter for orders that were later confirmed as fraud and for orders that were not, and place the limit above the ninety-ninth percentile of the legitimate group. Then review hit volume weekly.

Pros

• Baseline-derived limits fit your actual customer mix, including gifting, households with shared devices, and business buyers.
• Separate limits per dimension keep one noisy signal from blocking all traffic from a network.
• Weekly review surfaces thresholds that drift as seasonality and product mix change.

Cons

• Fixed thresholds decay; a limit tuned in November may be wrong in July.
• Small merchants lack the volume to build stable percentiles for every counter.
• Aggressive limits convert real buyers into declined orders, and the loss is invisible compared with fraud losses.

Use case: a merchant with heavy household sharing or business accounts should pair tight IP limits with step-up authentication instead of a hard decline, and should exclude allowlisted partner IPs from counter evaluation.

Criterion 4: Response actions and the review workflow

A velocity hit does not have to mean a block. Three responses cover most needs: decline, step up to 3D Secure, or hold for manual review. Reserve declines for clear multi-signal hits, route single-signal hits to step-up, and send ambiguous cases to a queue with the counter values attached so an analyst can judge quickly.

Pros

• Graduated responses protect conversion while still stopping repeated scripted attempts.
• Step-up authentication shifts chargeback liability when the issuer supports it.
• A review queue exposes rules that fire on good customers, giving you evidence to retune.

Cons

• Step-up adds friction and some buyers abandon at the challenge.
• Manual review costs staff time and slows fulfillment on held orders.
• Attackers adapt to any rule that stays fixed for long, so responses need periodic retesting.

Use case: a merchant without a dedicated fraud team should automate declines for high-confidence hits and route everything else to a daily review block, escalating to full-time review only if hold volume exceeds what one person can clear.

Pairing velocity with the checks you already run

Velocity works best as one layer. Combine it with CVV and address verification results, avoid retrying hard declines since repeated retries are themselves a testing signal, and share counter state across every sales channel. Review issuer response codes in aggregate: a cluster of invalid-card responses from one device tells you more than any single decline. None of this requires new infrastructure beyond a counter store and a rules layer, and the coverage improves with each dimension you add.