WooCommerce Card Testing Defense Pro: Auto-Escalation, Attack History, and When You Actually Need It
Store Security · TrustLens Pro
One Bot You Can Block. Ten Bots Need a Different Answer.
TrustLens Free stops individual card-testing devices the moment they hit velocity thresholds. But coordinated attacks — multiple bots, multiple IPs, launched simultaneously — outrun fingerprint-by-fingerprint blocks. This guide explains what TrustLens Pro adds at the attack-scale layer, how the geographic safeguard protects your flash-sale traffic from a false alarm, and how to decide whether the Pro layer is something your store actually needs.
Card testing attacks against WooCommerce stores come in two shapes. The first is a single automated device — one bot, one IP, cycling through stolen card numbers as fast as the checkout will process them. The second is coordinated: a botnet that distributes the same probing behavior across dozens of devices simultaneously, each one operating below the per-device threshold that would normally trigger a block.
TrustLens Free is well-suited to the first shape and partially effective against the second. TrustLens Pro closes the remaining gap with auto-escalation, a geographic-diversity safeguard, fingerprint and IP allowlists, and an Attack History tab that gives you forensic visibility after an attack concludes. This post covers how each of those features works at the code level, when they matter, and when they do not.
If you are not yet familiar with how card testing attacks work or what TrustLens Free does in response, the post on how WooCommerce card testing attacks work and what they cost covers that foundation. This post goes deeper on the Pro-tier features specifically.
What TrustLens Free Already Does
TrustLens Free includes a complete Card-Testing Defense module at no cost. Understanding the free baseline is important before evaluating what Pro adds — the free tier is not a stripped-down preview. It is a functional system with specific, verifiable capabilities.
When a device fingerprint accumulates declined payment attempts faster than the threshold allows — the default is 3 declines within a 60-second rolling window, or 10 checkout submissions in the same window — TrustLens blocks that device from completing further checkout attempts for 90 seconds. The block applies to both the JavaScript-derived fingerprint and a server-side fallback hash derived from IP address, browser user agent, and accept-language header. This means a bot that rotates its client-side fingerprint between requests still accumulates against a stable server-hash and gets targeted even if each client-hash is unique.
The VIP customer bypass is on by default. Customers with at least 3 completed orders who are not in the Risk or Critical trust segments are permanently exempt from velocity blocks. Your established customers cannot trigger a false positive regardless of how unusual their checkout session looks.
The admin dashboard shows the current defense state — IDLE, TARGETED, or PANIC — and a 24-hour decline count. There is a one-click Panic Freeze button that halts all checkout processing for a configurable duration (default 15 minutes, maximum 30 minutes per activation) when you need to buy time during an active attack that fingerprint blocks alone are not containing.
Free defense ships enabled by default
Card-Testing Defense is active on fresh TrustLens installations without any configuration. You do not need to enable it manually or set thresholds before you get baseline protection. The module starts blocking immediately after activation.
The Gap Free Cannot Close
The free tier’s defense model is per-device. Each fingerprint accumulates its own counter in a rolling time window. When that counter crosses the threshold, that fingerprint gets blocked.
This works very well against single-device attacks. A bot running from one IP — or even rotating IPs — still builds up a per-fingerprint count that eventually trips the threshold, and the server-side fallback hash catches rotation.
The scenario free does not automatically handle: a coordinated botnet where each participating device submits only one or two checkout attempts before moving on. If 20 devices each submit two declined attempts within a few minutes, no individual device crosses the per-device threshold, but your gateway is still absorbing 40 probes in a short window and accumulating decline ratio damage.
A human admin watching the dashboard could see this pattern — a sudden cluster of TARGETED states from many different fingerprints — and manually activate the Panic Freeze button. But that requires someone to notice in real time, which is not always the case at 2 AM on a Sunday.
Auto-escalation addresses this by measuring the attack at the store level, not the device level.
Auto-Escalation: How It Works Mechanically
TrustLens Pro’s auto-escalation feature monitors how many distinct device fingerprints trip the card-testing threshold within a 10-minute rolling window. When that count reaches 3, TrustLens automatically activates a 15-minute Panic Freeze — halting all checkout processing — rather than waiting for an admin to respond.
These numbers come directly from the plugin source. The auto-escalation class defines the window as 600 seconds (10 minutes), the threshold as 3 distinct fingerprints, and the automatic Panic Freeze duration as 900 seconds (15 minutes). There is nothing configurable about the window or threshold in the current version — both are constants.
Why 3 devices in 10 minutes?
A realistic card testing botnet will trip multiple fingerprints in a short burst — the whole point of distributing the attack is to generate more probes faster. Three distinct devices tripping the threshold within 10 minutes is an uncommon pattern for legitimate traffic and a common pattern for a coordinated attack. The threshold is low enough to catch early-stage coordinated attacks but high enough that isolated false triggers from coincidental timing are unlikely during normal trading hours.
Before activating the Panic Freeze, TrustLens consults the geographic-diversity checker (described in the next section). If the geographic check determines the burst looks like natural distributed traffic — flash sale customers from many countries — the escalation is held off. This gate is what prevents the auto-escalation feature from causing collateral damage during legitimate traffic surges.
If the geographic check passes or is inconclusive, the Panic Freeze activates. The freeze lasts 15 minutes and then releases automatically. If the attack resumes immediately, the fingerprint counters begin accumulating again from zero and the escalation logic can fire a second time. There is no cooling-off period that permanently prevents re-escalation.
How this differs from the manual Panic Freeze button
The manual Panic Freeze button available in TrustLens Free and Pro is an admin-activated control. Someone has to see the attack and click it. The button fires the same 15-minute freeze, but a human is in the loop.
Auto-escalation removes that human dependency for coordinated multi-device attacks. It fires within seconds of the third fingerprint tripping the threshold — before a human admin would have had time to notice the dashboard state, recognize the pattern, and click the button. For stores where the admin is not monitoring TrustLens in real time, that response-time difference is the practical value of the feature.
The Geographic-Diversity Safeguard
The geographic-diversity safeguard is the feature that makes auto-escalation viable for stores that run international flash sales or go viral.
The problem it solves: a genuine surge of interest in your store from many different countries looks, at the fingerprint layer, like exactly what an auto-escalation trigger looks for. Many distinct devices. Rapid checkout attempts. Multiple declines as customers encounter regional payment friction or test-drive coupons. Without a geographic check, a flash sale that drives international traffic could trigger an automatic Panic Freeze that locks out all of those customers.
The geographic check works as follows. When the 3-fingerprint threshold is reached, TrustLens counts the distinct countries represented by the attacking device IPs using WooCommerce’s built-in geolocation. It then applies two conditions:
- The burst must represent traffic from at least 10 distinct countries.
- No single country can account for more than 50% of the attack traffic.
If both conditions are met, TrustLens treats the burst as naturally distributed traffic and does not escalate. The threshold holds: at least 10 countries, no single country majority.
If the burst is concentrated — 3 devices, all from the same country, or all from two countries — the check fails (too few countries) and the escalation proceeds.
The logic is sound because botnet traffic is typically not well-distributed geographically. Botnets tend to cluster in regions where compromised device infrastructure is cheap or where they are operated from. Genuinely distributed flash-sale traffic, by contrast, tends to spread across many countries because that is what “international interest” actually looks like.
Edge case: regional flash sales
If your flash sale is explicitly regional — promoted only in one or two countries — a coordinated attack launched at the same time could potentially pass the geographic check. The safeguard is built for international traffic patterns; highly concentrated regional sales offer less of a distinguishing signal. This is an edge case, not a common scenario, but worth knowing if you run narrow regional promotions.
Fingerprint and IP CIDR Allowlists
TrustLens Pro adds two types of allowlist entries for card-testing defense: device fingerprint allowlists and IP CIDR range allowlists. Both operate as bypass rules — a matching fingerprint or IP skips all card-testing defense checks, including velocity detection, before any blocking rule runs.
When fingerprint allowlists matter
If your team uses automated checkout testing as part of a CI/CD pipeline, those test runs look exactly like card-testing bot behavior: many rapid checkout submissions in a short window, likely from a consistent device fingerprint. Without an allowlist entry, your QA runs will trip the velocity threshold and get blocked from completing checkout, which breaks your test pipeline.
Adding the QA device’s fingerprint to the allowlist bypasses the velocity check for that specific device. Legitimate card-testing defense still applies to everything else.
When IP CIDR allowlists matter
Integration partners, payment gateway sandbox environments, and load-testing services often operate from known IP ranges. You can add those ranges in CIDR notation — both IPv4 and IPv6 ranges are supported — to exempt them from card-testing checks. This is also the right approach for Stripe testing infrastructure or similar services that your payment gateway uses for health checks.
The allowlist is a bypass, not a trust signal. Adding a fingerprint or IP to the card-testing allowlist does not affect that device’s standing in TrustLens’s customer trust scoring. It only exempts it from the velocity-based checkout blocks.
What allowlists do not do
Allowlists do not affect the customer email block list. If a customer email address is blocked in TrustLens, the block still applies regardless of whether the device fingerprint or IP is on the card-testing allowlist. The two systems are independent.
The Attack History Tab
TrustLens Pro adds an Attack History tab to the Card-Testing Defense admin page. The tab shows a rolling 24-hour view of every velocity event — every checkout attempt that was flagged or blocked by the card-testing module — with detail that lets you reconstruct what happened after the fact.
The tab shows:
- Total 24-hour decline count — the aggregate number of blocked or flagged attempts in the current window
- Decline-code breakdown — how many declines were CVC mismatches, AVS failures, insufficient funds, card not found, and so on, so you can understand what the bots were doing
- Top-10 attacking fingerprints — the device fingerprint hashes with the most recorded velocity events, ranked by count
- Hourly timeline chart — a Chart.js visualization of velocity events by hour so you can see when the attack started, how long it lasted, and when it subsided
- CSV export — a full export of all velocity events in the 24-hour window, including timestamps, fingerprint hashes, IP addresses, and decline codes
What the Attack History tab is useful for
The primary use case is post-attack investigation. After a card-testing episode, the Attack History tab lets you answer specific questions: How many devices were involved? When exactly did the attack start and end? Were there patterns in the decline codes that suggest what data the bots had? Which fingerprints were most active?
The CSV export is particularly useful if you want to cross-reference attack fingerprints with completed orders in the same time window. If any of the attacking device fingerprints match fingerprints on completed orders, those orders carry elevated fraud risk and warrant a manual review before fulfillment.
The tab is also useful for ongoing pattern detection. If you see a recurring spike in the hourly timeline at a consistent time of day, that suggests a scheduled attack rather than an opportunistic one. Knowing that, you can configure gateway-level rate limits to be tighter during those hours, or use TrustLens Pro’s Automation Rules to escalate the response at those specific times.
The 24-hour window is rolling, not calendar-day
The Attack History tab shows the 24 hours preceding the current time, not yesterday’s data. The plugin’s velocity events table is trimmed periodically — the default retention window is 48 hours, configurable between 24 and 168 hours in settings. If you want to retain attack history for longer forensic review, increase the retention window before an attack clears the buffer.
Slack and Email Alerts
TrustLens Pro includes an alert dispatcher that sends notifications to a configured Slack webhook and/or email address when specific card-testing events occur. The dispatcher subscribes to three events:
- attack_detected — fires when a single device fingerprint first trips the velocity threshold (i.e., when a targeted lockout is created)
- auto_escalated — fires when the auto-escalation threshold is crossed and a Panic Freeze is automatically activated
- panic_button_activated — fires when an admin manually activates the Panic Freeze button
Alert delivery is asynchronous — the dispatcher schedules a background WP-Cron event rather than blocking the gate or the admin AJAX request. A slow Slack webhook or a mail delivery delay does not affect the checkout experience.
What the alerts contain
The attack_detected alert includes the attacking fingerprint hash, the IP address, and the customer email if the request was tied to a known customer. The auto_escalated alert includes the freeze duration in seconds and the count of distinct attackers that triggered escalation. The panic_button_activated alert includes the duration.
The Slack alert format uses the Slack Incoming Webhooks attachment structure, so each field renders as a labeled key-value pair in your Slack channel. The email format is a plain-text summary of the event and data.
Practical use of the alerts
The most useful alert is auto_escalated. When you receive it, you know a coordinated attack just triggered an automatic Panic Freeze. The 15-minute window gives you time to log into your admin, review the Attack History tab, decide whether to extend the freeze manually, and check your gateway dashboard for how many declines accumulated before the freeze activated.
The attack_detected alert fires on every new fingerprint block, which can mean multiple alerts during a fast-moving attack. If your store is under active attack, the Slack channel will receive a message for each new fingerprint that trips the threshold. This is useful for high-traffic stores that want granular visibility; it can feel noisy for stores where a single targeted fingerprint is the typical scenario. There is currently no batching or digest mode for this alert.
When the Free Tier Is Genuinely Enough
The honest question to answer before investing in any Pro upgrade is whether the problem it solves is actually a problem you have. The TrustLens Pro card-testing features are well-built and do what they say, but they address a specific scenario — coordinated multi-device attacks — that is not the most common form of card testing against small and mid-sized WooCommerce stores.
| Your store’s situation | Free tier likely sufficient? |
|---|---|
| Modest traffic, attacks tend to be single-device bursts | Yes — per-fingerprint blocks handle this well |
| Admin monitors the dashboard and can respond manually during business hours | Yes — manual Panic Freeze is available in Free |
| Store does not have QA automation testing the checkout | Yes — no need for allowlists |
| Attacks are infrequent, no post-attack forensics needed | Yes — no persistent attack history needed |
| Coordinated multi-device attacks (3+ fingerprints, simultaneous) | Pro recommended — auto-escalation handles the response without human intervention |
| Store is unmonitored at night or on weekends | Pro recommended — auto-escalation fires even when nobody is watching |
| CI/CD pipeline tests checkout automatically | Pro recommended — allowlists prevent QA from being blocked |
| High-volume store with meaningful gateway fee exposure during attacks | Pro recommended — faster automated response reduces the fee accumulation window |
| Runs international flash sales with distributed traffic spikes | Depends — Free handles the defense correctly, but Pro’s geographic safeguard prevents auto-escalation from misfiring on legitimate traffic |
The underlying principle: TrustLens Free protects against the card testing attacks that most WooCommerce stores actually encounter. TrustLens Pro is for stores where the attack surface is larger — higher order volume, longer unmonitored windows, automated testing infrastructure, or a pattern of coordinated attacks — and where the automated response and forensic tools are worth the upgrade cost.
If you are unsure which category your store is in, start with the free tier. The Attack History tab in Pro would tell you whether you have experienced multi-device attacks, but the TARGETED state count on the Free dashboard is also diagnostic: if you regularly see multiple TARGETED states in the same short window, that is the signal to look at Pro.
For a broader comparison of what TrustLens Free and Pro include across all features — not just card testing — the TrustLens Free vs Pro breakdown covers the full feature boundary with verified detail. And if you are thinking about how TrustLens card-testing defense interacts with your discount campaigns — since both run at checkout simultaneously — the guide to how Smart Cycle Discounts and TrustLens work together explains how the two systems relate at the checkout layer.
The practical guide to WooCommerce fraud prevention is a good companion for understanding where card testing sits in the broader fraud landscape — how it differs from behavioral fraud, what it costs before any orders succeed, and how it interacts with your chargeback ratio over time.
The Practical Summary
- TrustLens Free already handles single-device attacks. Per-fingerprint velocity blocks fire within seconds of the threshold being crossed. The VIP bypass, server-side fallback hash, and manual Panic Freeze button are all included at no cost.
- The Pro layer adds a store-level response. When 3 or more distinct device fingerprints trip the velocity threshold within 10 minutes, auto-escalation activates a 15-minute Panic Freeze automatically — without waiting for an admin to notice.
- The geographic safeguard prevents false alarms. If the triggering devices are spread across 10 or more countries with no single country above 50%, TrustLens treats the burst as natural distributed traffic and holds off on escalation. This protects genuine flash-sale or viral traffic from being blocked.
- Allowlists solve the QA problem. If your team runs automated checkout tests or uses known IP ranges for integration work, fingerprint and IP CIDR allowlists let those requests bypass velocity checks without disabling the protection for everyone else.
- The Attack History tab is retrospective, not real-time. It answers “what happened during that attack?” — decline-code breakdown, top attacking fingerprints, hourly timeline, CSV export. Useful for forensics and for spotting recurring attack patterns.
- Slack and email alerts let you know in real time. The
auto_escalatedalert is the most actionable — it fires the moment auto-escalation activates, giving you a notification and a window to review before the freeze expires. - Many stores do not need Pro for card testing. If attacks on your store have been single-device, you monitor the dashboard regularly, and you do not have automated checkout testing, the free tier covers your real exposure. Upgrade when the automated response and forensic tooling become worth the cost for your volume and risk profile.
Frequently Asked Questions
What exactly triggers TrustLens Pro auto-escalation?
TrustLens Pro auto-escalation activates a Panic Freeze when 3 or more distinct device fingerprints each trip the card-testing velocity threshold within a rolling 10-minute window, and the geographic-diversity check does not identify the burst as naturally distributed international traffic. Each of those numbers — 3 fingerprints, 10 minutes — comes from the plugin’s auto-escalation class constants. The Panic Freeze that auto-escalation triggers lasts 15 minutes and releases automatically.
What happens if the geographic-diversity check cannot resolve country data?
The geographic check uses WooCommerce’s built-in geolocation. If WooCommerce geolocation is not available, or if an IP address cannot be resolved to a country, the geographic check returns false — meaning the check does not indicate natural traffic, and the escalation proceeds. The same happens when any of the attacking devices have empty or unresolvable IPs. The geographic safeguard is a hold-off mechanism; when it cannot confirm natural distribution, escalation is the safer default.
Does auto-escalation prevent manual Panic Freeze from working?
No. The manual Panic Freeze button is always available in both Free and Pro. Auto-escalation adds an additional trigger for activating the same freeze; it does not disable or interfere with the manual path. If auto-escalation already activated a freeze and you want to extend it, click the Panic Freeze button before the current freeze expires and a fresh 15-minute (or longer, up to the 30-minute maximum) window starts.
How do I add a device fingerprint to the card-testing allowlist?
The fingerprint and IP CIDR allowlist is managed in TrustLens settings under the Card-Testing Defense Pro section. You can add individual device fingerprint hashes or IP address ranges in CIDR notation. To find the fingerprint hash for a specific device, look at the Attack History tab’s top-attacking fingerprints list, or use browser developer tools to inspect the fingerprint value that TrustLens collects on checkout. The allowlist takes effect immediately on save.
Does TrustLens Pro card-testing defense affect behavioral trust scores?
Yes, but only in one direction. When a device fingerprint is involved in a card-testing attack, TrustLens records a negative trust-score signal on any customer account linked to that fingerprint. This is a free-tier behavior — the signal fires even without Pro. The Pro allowlist does not prevent this; if an allowlisted device is involved in what TrustLens sees as attack traffic, the signal may still fire on the linked customer. Allowlists bypass checkout blocking, not behavioral scoring.
Is the 24-hour window in the Attack History tab configurable?
The Attack History tab always shows the rolling 24 hours. What is configurable is the underlying retention window for velocity events — how long the raw event data is kept. The default retention is 48 hours; you can extend it up to 168 hours (7 days) in TrustLens settings. The Attack History tab display window is fixed at 24 hours regardless of retention setting.
Does TrustLens Pro replace gateway-level fraud tools like Stripe Radar?
No — and it is not designed to. Stripe Radar and similar gateway-level tools operate at the card data layer: they see card numbers, issuing banks, BIN ranges, and AVS/CVC results. TrustLens operates at the behavioral layer: device fingerprints, velocity patterns, customer history. The two tools see different signals and complement each other. Running both gives you defense in depth: gateway tools catch card-level fraud patterns, TrustLens catches device behavioral patterns and post-attack customer risk. For stores with meaningful attack exposure, the right configuration is both, not one or the other.
Baseline protection is free
TrustLens Card-Testing Defense — velocity detection, per-fingerprint blocks, VIP bypass, manual Panic Freeze — is included in the free version with no trial limits. Pro adds auto-escalation for coordinated attacks, the geographic-diversity safeguard, allowlists, the Attack History tab, and Slack and email alerts.
