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 authorization attempts as they happen, detects velocity patterns consistent with automated card-testing, and locks out the attacker’s device fingerprint before further attempts can be processed.

Module ID: card_testing. Default: enabled. Free tier (velocity detection, fingerprint lockouts, Panic Freeze, VIP bypass). Pro adds auto-escalation, geo-diversity safeguard, allowlists, advanced fingerprinting, Attack History, and Slack alerts.

---

What It Observes #

The module sits in the checkout request path through the unified Request Gate. For each authorization attempt — successful or declined — it:

1. Captures a device fingerprint (user-agent, accept-language, viewport, canvas hash, and in Pro a 12-font detection signal)
2. Records the decline code if the attempt failed
3. Updates per-fingerprint counters in a 60-second rolling window
4. Checks the counters against velocity thresholds
5. If thresholds are exceeded: locks the fingerprint out for 90 seconds and rejects subsequent attempts immediately
6. Fires the trustlens/card_testing/attack_detected action for automation rules and alerts

Detection happens before the payment gateway is hit. This is the key difference from gateway-side fraud detection: TrustLens never lets the bot make the second decline because the second request never reaches the gateway.

---

The Velocity Window #

Window	Default Threshold	What It Catches
60-second rolling — declines	3 declines per fingerprint	Burst attacks — automated tools hammering the gateway with stolen cards
60-second rolling — submissions	10 submissions per fingerprint	Bots that include some successful auths in the burst, raising overall submission volume

When either threshold is crossed, the fingerprint is locked. The base module’s lockout is 90 seconds — long enough to make further attempts uneconomical for the attacker, short enough that legitimate users who hit the threshold by accident get back into the flow quickly.

The base module runs only a 60-second rolling window. The longer 10-minute attack-scale check ships in Pro auto-escalation — it watches for attacks that spread across multiple fingerprints within 10 minutes and triggers Panic Freeze automatically. See Auto-Escalation (Pro).

---

The Lockout #

While locked (90 seconds by default), the fingerprint 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.

The lockout is keyed by fingerprint, not by IP, because card-testing botnets often rotate IPs. Fingerprint-based lockouts catch the bot even when it switches IP addresses between attempts.

---

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 for the full rules.

---

Panic Freeze #

For attacks that escalate beyond what per-fingerprint lockouts can absorb, the Panic Freeze button halts all checkouts for 5, 15, or 30 minutes (default 15). Located on the TrustLens → Card-Testing Defense page (and accessible from the Dashboard).

One click triggers the freeze. While active:

• Every checkout attempt is rejected at the Request Gate
• A banner appears across the admin showing freeze status and remaining time
• The freeze can be canceled manually before its duration expires
• VIP bypass still applies — VIPs can still check out during a freeze if bypass is enabled

Panic Freeze is the right tool for the worst-case scenario: an attack distributed across enough fingerprints 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.

---

What It Signals #

Card-Testing Defense’s primary action is preventive — locking out fingerprints. But it also contributes signals to the trust scores of customers whose emails subsequently complete orders using fingerprints involved in past attacks.

Trigger	Score	Reason Shown on Profile
Customer fingerprint matched recent attack (within 7 days)	-20 to -40	“Fingerprint tied to recent card-testing attack”
Customer fingerprint matched historical attack (older than 7 days)	-10	“Historical card-testing fingerprint match”

This is the bridge between checkout-time enforcement and customer trust scoring. If a fingerprint that hammered your gateway later completes a successful order, that customer’s score reflects the association.

---

Settings #

Setting	Default	Description
60-second decline threshold	3 declines	Declines per fingerprint in 60s that trigger lockout
60-second submission threshold	10 submissions	Total checkout submissions per fingerprint in 60s
Lockout duration	90 seconds	How long a fingerprint stays locked after threshold breach
VIP customer bypass	On	VIPs skip velocity checks
Module enabled	On	Master toggle

---

Pro Enhancements #

Auto-Escalation #

Pro can automatically escalate from per-fingerprint lockouts to full Panic Freeze when an attack spreads across multiple fingerprints. Default trigger: 3 distinct fingerprints hitting velocity thresholds within a 10-minute window. When triggered, the system fires the Panic Freeze automatically and sends an alert.

Geographic-Diversity Safeguard #

Before auto-escalating, Pro checks the geographic distribution of the declining fingerprints. If declines are spread across ≥10 countries with no single country contributing >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 fingerprints and IP ranges:

• Fingerprint allowlist for QA tools, integration partners, or specific known devices
• IP CIDR allowlist supporting both IPv4 and IPv6 ranges
• Per-fingerprint threshold overrides for cases where a specific device legitimately produces high velocity

Advanced Fingerprint Signal #

The Free fingerprint uses user-agent, accept-language, viewport, and canvas hash. 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 Tab #

Pro’s TrustLens → Card-Testing Defense → Attack History tab shows:

• 24-hour decline count with sparkline
• Decline-code breakdown (insufficient funds, invalid expiry, fraud-suspect, etc.)
• Top-10 attacking fingerprints with their decline counts
• Hourly timeline chart for the last 7 days
• CSV export of all velocity events

Slack and Email Alert Dispatcher #

Pro sends alerts on three events:

• attack_detected — a fingerprint hits velocity thresholds
• auto_escalated — Panic Freeze auto-triggered by escalation rules
• panic_button_activated — Panic Freeze manually triggered

Both Slack and email channels supported. See Auto-Escalation (Pro) for the configuration.

---

Common Patterns #

The Classic Burst Attack #

Signature: 50+ decline attempts from a single fingerprint within 60 seconds, all with different card numbers.

Detection: 60-second threshold triggers after attempt 3. Lockout for 90 seconds. Bot moves on.

Effective: Almost always — bots usually give up on the locked fingerprint after one cycle.

The Slow-Sustained Attack #

Signature: 2 declines per minute, paced specifically to stay under the 60-second threshold.

Detection: Base 60-second window catches it once the slow pace accumulates 3 declines within a single minute. For attacks pacing below that (e.g. 1 decline every 90 seconds), the base module misses them and Pro auto-escalation across multiple fingerprints is the right defense.

Profile: Lockout kicks in around minute 6 of the attack.

The Distributed Botnet #

Signature: Declines spread across 50+ fingerprints, each making 2–3 attempts to stay below per-fingerprint thresholds.

Detection (Free): Velocity rules don’t catch this; Panic Freeze required.

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-fingerprint thresholds occasionally trigger (3 declines from one customer is possible if they fumble cards); VIP bypass protects loyal customers; Panic Freeze is not triggered because fingerprints are diverse.

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’s email is associated with a flagged fingerprint
• Event timeline shows decline and during_attack_window entries with timestamps and decline codes
• Fingerprint panel (Pro) shows which device fingerprints are associated with the customer and their attack history

For dispute defense, the Card-Testing signal on a customer who later files a chargeback is strong evidence — it shows the card was tested against your store before the order, which a legitimate cardholder would never do.