--- title: Card Testing Defense description: "Card-testing attacks are the most active, real-time threat WooCommerce stores face. Fraudsters with lists of stolen card numbers use automated tools to probe gateways with small test transactions, looking for cards that still work. A successful attack against your store…" url: "https://webstepper.io/docs/trustlens/detection-modules/card-testing-defense/" updated: "2026-10-18" category: Detection Modules --- # Card Testing Defense Card-testing attacks are the most active, real-time threat WooCommerce stores face. Fraudsters with lists of stolen card numbers use automated tools to probe gateways with small test transactions, looking for cards that still work. A successful attack against your store can produce thousands of authorization attempts per hour, generate gateway fees on every decline, hammer your conversion metrics, and — most damaging — produce downstream chargebacks weeks later when the real cardholders notice the fraud. Card-Testing Defense is the only TrustLens module that operates at request-time rather than post-event. It watches checkout attempts as they happen, detects velocity patterns consistent with automated card-testing, and locks out the attacker's device *before* further attempts can be processed. Module ID: `card_testing`. Default: enabled. Free tier (velocity detection, escalating device lockouts, Panic Freeze, VIP bypass, optional Cloudflare Turnstile browser challenge). Pro adds auto-escalation, geo-diversity safeguard, allowlists, an advanced fingerprint signal, 24-hour attack intelligence, and Slack/email alerts. --- ## What It Observes The module sits in the checkout request path through the unified Request Gate — classic checkout, block (Store API) checkout and the pay-for-order page. For each checkout submission and each declined payment it: 1. Identifies the device two ways: a browser fingerprint computed in the shopper's browser (canvas rendering, screen size and pixel ratio, timezone, language, platform and WebGL renderer — plus, in Pro, a 12-font detection signal) and a server-side fingerprint built from the IP address, user-agent and Accept-Language header 2. Records the decline code if the attempt failed 3. Updates per-device counters over a 60-second window and a 1-hour window 4. Checks the counters against velocity thresholds 5. If a threshold is crossed: locks the device out (90 seconds the first time, longer for repeat offenders) and rejects its subsequent attempts immediately 6. Fires the `trustlens/card_testing/attack_detected` action for automation rules and alerts Checks happen before the request reaches the payment gateway. This is the key difference from gateway-side fraud detection: once a device crosses a threshold, its further attempts never reach the gateway. --- ## The Velocity Window | Window | Default Threshold | What It Catches | | --- | --- | --- | | 60 seconds — declines | 3 declines per device | Burst attacks — automated tools hammering the gateway with stolen cards | | 60 seconds — submissions | 10 submissions per device | Bots that include some successful auths in the burst, raising overall submission volume | | 1 hour — declines | 8 declines per device | Slow attacks — a bot that paces itself under the 60-second rules, or waits out each lockout and starts over | When any threshold is reached, the device is locked. Because the browser fingerprint and the server-side fingerprint are both checked, a bot can't escape by rotating its browser signature. The longer 10-minute, store-wide attack check (attacks spread across many devices) ships in **Pro auto-escalation** — it triggers Panic Freeze automatically. See [Auto-Escalation (Pro)](/docs/trustlens/card-testing-defense/auto-escalation/). --- ## The Lockout The lockout grows with each time the same device is caught: **90 seconds** the first time, then **15 minutes**, **1 hour** and **24 hours** for repeat offenders (strikes are counted within the event-retention window, 48 hours by default). While locked, the device cannot complete checkout. The Request Gate intercepts the request before it reaches the payment gateway and returns a generic error. The error message is intentionally non-specific — it doesn't tell the bot it's been detected, only that the request failed. A caught device is also flagged, which feeds the trust-score signal below. You can release a held device from the Card-Testing Defense page, which clears its lockout, strikes and flag. --- ## VIP Customer Bypass VIP customer bypass is on by default. Despite the name, it isn't limited to the VIP segment: when the billing email at checkout matches an established customer — one with at least the minimum-orders threshold of completed orders (default 3) who isn't in the Risk or Critical segment — the velocity counters skip them. This prevents a key class of false positive: a returning trusted customer placing an order with a card that triggers multiple expiry-date failures before they get it right. Without the bypass, the customer could get locked out of their own checkout. A single completed order is deliberately not enough to qualify, so a fraud actor can't earn permanent immunity by buying once. The bypass can be turned off on the **TrustLens → Card-Testing Defense** page if your store has specific reasons to enforce velocity on every customer. See [VIP Customer Bypass](/docs/trustlens/card-testing-defense/vip-bypass/) for the full rules. --- ## Panic Freeze For attacks that escalate beyond what per-device lockouts can absorb, the **Panic Freeze** button halts *all* checkouts for 5, 15, or 30 minutes (default 15). It's on the **TrustLens → Card-Testing Defense** page; the Dashboard's Command Center links straight to it. One click triggers the freeze. While active: - Every checkout submission is rejected at the Request Gate (carts are left alone) - The freeze shows in the TrustLens header status, as a "Panic Freeze Active" alert on the Dashboard, in the WordPress Dashboard widget, and on the Card-Testing Defense page - The freeze can be canceled manually with **Deactivate Freeze** before its duration expires - VIP bypass does *not* apply — the freeze blocks everyone. Only store staff (users who can manage WooCommerce) and, in Pro, allowlisted devices and IP ranges get through Panic Freeze is the right tool for the worst-case scenario: an attack distributed across enough devices that velocity rules aren't catching them in time. The 15-minute window gives you time to investigate (see who's attacking, what cards they're using, whether geolocation patterns suggest a specific botnet) and decide on a longer-term response. --- ## Browser Challenge (Cloudflare Turnstile) Since 1.3.14, Free includes an optional browser challenge that runs before any payment reaches your gateway. It stops the attacker velocity rules can't see — one who presents a fresh identity on every attempt. It's off until you add free Cloudflare Turnstile keys and switch it on in the **Browser Challenge** panel on the Card-Testing Defense page (a **Test connection** button checks the keys). Three settings for who gets challenged: - **Suspicious checkouts only** (recommended, default) — only checkouts that look automated; a shopper who browsed, built a cart and filled in the form is never challenged - **Anyone without a purchase history** - **Every checkout** — for use while an attack is live If Cloudflare can't be reached, checkout continues — the challenge never closes your store. --- ## What It Signals Card-Testing Defense's primary action is preventive — locking out devices. But it also contributes a signal to the trust score of customers who checked out from a device it caught. | Trigger | Score | Reason Shown on Profile | | --- | --- | --- | | Customer linked to 1+ device fingerprints caught card testing | -30 | "Linked to 1 device fingerprint(s) involved in a card-testing attack" | This is the bridge between checkout-time enforcement and customer trust scoring. The link comes from the checkout velocity events, so the signal lasts only as long as those events are retained (48 hours by default), and like the other history modules it applies once the customer has reached the Full-confidence Order Threshold. --- ## Settings | Setting | Default | Description | | --- | --- | --- | | **Declines in 60s** | 3 declines | Declines per device in 60 seconds that trigger a lockout | | **Submissions in 60s** | 10 submissions | Total checkout submissions per device in 60 seconds | | **Declines in 1 hour** | 8 declines | Declines per device in an hour — catches slow, paced attacks | | **Event retention** | 48 hours | How long velocity events (and lockout strikes) are kept, 24–168 hours | | **VIP customer bypass** | On | Established customers skip velocity checks | | **Module enabled** | On | Master toggle (on the Card-Testing Defense page) | The lockout durations (90 seconds → 15 minutes → 1 hour → 24 hours) are not a setting; developers can change them with the `trustlens/card_testing/lockout_seconds` filter. --- ## Pro Enhancements ### Auto-Escalation Pro can automatically escalate from per-device lockouts to full Panic Freeze when an attack spreads across multiple devices. Trigger: 3 distinct devices hitting velocity thresholds within a 10-minute window. When triggered, the system starts a 15-minute Panic Freeze automatically and raises an alert. ### Geographic-Diversity Safeguard Before auto-escalating, Pro checks the geographic distribution of the declining devices (using WooCommerce's IP geolocation). If declines come from 3 or more countries with no single country contributing more than 50%, the safeguard *blocks* the auto-escalation — that pattern looks more like legitimate viral or flash-sale traffic than an attack. This prevents Panic Freeze from triggering on Black Friday spikes. ### Fingerprint and IP CIDR Allowlists Pro adds explicit allowlist surfaces for known-good devices and IP ranges: - Fingerprint allowlist for QA tools, integration partners, or specific known devices - IP CIDR allowlist supporting both IPv4 and IPv6 ranges Allowlisted traffic bypasses the defense entirely, including Panic Freeze and the browser challenge. ### Advanced Fingerprint Signal The Free browser fingerprint uses canvas rendering, screen characteristics, timezone, language, platform and WebGL renderer. Pro adds a 12-font detection signal — measuring whether each of 12 specific fonts is installed by comparing baseline character widths. This is harder for botnets to spoof consistently across nodes because each compromised host has its own real font set. ### Attack History Pro's **24-hour intelligence** panel on the TrustLens → Card-Testing Defense page shows: - Decline-code breakdown (insufficient funds, invalid expiry, fraud-suspect, etc.) - Top-10 attacking fingerprints with their decline counts - Hourly timeline chart for the last 24 hours - CSV export of velocity events The 24-hour decline count, submissions and decline rate are shown to everyone at the top of the page. ### Slack and Email Alert Dispatcher Pro sends alerts on three events: - `attack_detected` — a device hits velocity thresholds - `auto_escalated` — Panic Freeze auto-triggered by escalation rules - `panic_activated` — Panic Freeze manually triggered Both Slack and email channels supported. See [Auto-Escalation (Pro)](/docs/trustlens/card-testing-defense/auto-escalation/) for the configuration. --- ## Common Patterns ### The Classic Burst Attack **Signature:** 50+ decline attempts from a single device within 60 seconds, all with different card numbers. **Detection:** 60-second threshold triggers at decline 3. Lockout for 90 seconds; if the bot comes back, 15 minutes, then 1 hour, then 24 hours. **Effective:** Almost always — bots usually give up on the locked device after one or two cycles. ### The Slow-Sustained Attack **Signature:** 2 declines per minute, paced specifically to stay under the 60-second threshold. **Detection:** The 1-hour window (8 declines per device) catches it. Even a bot pacing at 1 decline every 90 seconds reaches 8 declines within the hour. **Profile:** Lockout kicks in around minute 4 of a 2-per-minute attack (around minute 11 at one decline every 90 seconds). ### The Distributed Botnet **Signature:** Declines spread across 50+ devices, each making 2–3 attempts to stay below per-device thresholds. **Detection (Free):** Velocity rules don't catch this; turn on the browser challenge or use Panic Freeze. **Detection (Pro):** Auto-escalation catches it. Geo-diversity safeguard distinguishes from legitimate viral traffic. ### The Legitimate Burst **Signature:** Black Friday flash sale; customers hammer the checkout; some get expiry validation failures. **Detection:** Per-device thresholds occasionally trigger (3 declines from one customer is possible if they fumble cards); VIP bypass protects loyal customers; nothing freezes checkout in Free unless you press Panic Freeze. **Profile:** Some false-positive lockouts on individual customers. Pro's geo-diversity safeguard prevents the auto-escalation. --- ## False-Positive Watch List - **Slow / shared payment processors.** Some gateways produce technical failures (timeouts, network errors) that look like declines. Tune the threshold up if your gateway is unreliable. - **B2B customers with stored payment methods.** Sometimes hit expiry mismatches on saved cards. VIP bypass usually handles this. - **QA test traffic.** Internal testing can trigger velocity. Add the QA fingerprint to the allowlist (Pro). - **Mobile users on flaky networks.** Retry behavior can produce false declines. Modern phones rarely trigger; older Android browsers can. --- ## Disabling the Module Disabling Card-Testing Defense is only sensible if you have a separate WAF or gateway-level card-testing protection you trust completely. The cost of disabling is high — card-testing attacks are common, expensive, and produce chargebacks weeks later that are difficult to dispute. --- ## Reading Card-Testing Data on a Customer Profile - **Signal breakdown** shows a Card-Testing signal if the customer checked out from a device that was caught (while the velocity events are retained) - **Event timeline** shows a `during_attack_window` entry when the customer's order was completed while card-testing defenses were active Declines themselves are recorded per device, not on the customer timeline. For dispute defense, an order completed during an attack window — or a Card-Testing signal on a customer who later files a chargeback — is useful evidence that the card was being tested against your store around the time of the order.