Card Testing Defense
7 min read
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:
- Captures a device fingerprint (user-agent, accept-language, viewport, canvas hash, and in Pro a 12-font detection signal)
- Records the decline code if the attempt failed
- Updates per-fingerprint counters in two rolling windows: 60 seconds and 10 minutes
- Checks the counters against velocity thresholds
- If thresholds are exceeded: locks the fingerprint out for 60 seconds and rejects subsequent attempts immediately
- Fires the
trustlens/card_testing_eventaction 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 60 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 (60 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. When a customer with a VIP segment authenticates at checkout (logged-in user OR billing email matches a VIP record), the velocity counters skip them.
This prevents a key class of false positive: a returning VIP 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. With the bypass, only authenticated non-VIP traffic is subject to velocity rules.
The bypass can be turned off in Settings → Modules → Card Testing if your store has specific reasons to enforce velocity on VIPs.
Panic Freeze #
For attacks that escalate beyond what per-fingerprint lockouts can absorb, the Panic Freeze button halts all checkouts for 15 minutes. Located on the TrustLens → Card Testing 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 the 15 minutes 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 | 60 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 → 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 thresholdsauto_escalated— Panic Freeze auto-triggered by escalation rulespanic_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 60 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
card_testing_evententries 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.
