Overview
Card-Testing Defense is TrustLens’s real-time checkout protection layer. While the other detection modules analyze customer behavior after the fact, Card-Testing Defense operates at request time — intercepting checkout attempts as they happen and blocking the devices behind automated card-testing attacks before the payment gateway is ever called. This page is the orientation document for the feature; the rest of this section covers each component in detail.
What a Card-Testing Attack Looks Like #
A card-testing attack is an automated probe of stolen card data. Fraudsters with lists of credit card numbers run them through your checkout in batches — usually small dollar amounts ($1–$5) — to identify which cards are still valid. Successful tests get resold or used elsewhere. The damage to your store:
- Gateway fees — every decline costs you
- Conversion metrics — your decline rate skews your analytics
- Downstream chargebacks — real cardholders dispute the test charges weeks later
- Card-network monitoring exposure — disputes and fraud reports push you toward the Visa VAMP and Mastercard ECP thresholds
Attacks typically run for 10 minutes to several hours, generating anywhere from dozens to thousands of authorization attempts.
The Defense Architecture #
TrustLens defends in layers, each catching different attack patterns:
| Layer | Catches | Free / Pro |
|---|---|---|
| Velocity detection per fingerprint | Bursts (60-second window) and slow, paced attacks (1-hour window) from a single device | Free |
| Fingerprint lockouts | Holds a device that crossed a threshold: 90 seconds the first time, then 15 minutes, 1 hour, and 24 hours for repeat offenders | Free |
| VIP customer bypass | Prevents established customers from being false-positived by the velocity rules | Free |
| Panic Freeze | Manual emergency stop — halts all checkout submissions for 5, 15, or 30 minutes (default 15) | Free |
| Browser Challenge (Cloudflare Turnstile) | Attackers who change identity on every attempt, which velocity counting can’t see | Free |
| Auto-escalation | Automatic Panic Freeze when an attack spreads across fingerprints | Pro |
| Geo-diversity safeguard | Prevents auto-escalation on legitimate viral / flash-sale traffic | Pro |
| Fingerprint / IP allowlists | Excludes QA, integration partners, known-good traffic | Pro |
| Advanced fingerprint (12-font) | Harder to spoof across botnet nodes | Pro |
| 24-hour intelligence | Hourly timeline, decline codes, top attacking fingerprints, CSV export | Pro |
| Email + Slack alerts | Notification on attack_detected / auto_escalated / panic_activated (no settings screen — set by option) | Pro |
What’s Enabled Out of the Box #
Card-Testing Defense ships enabled with sensible defaults:
- Declines in 60 seconds: 3 per fingerprint
- Submissions in 60 seconds: 10 per fingerprint
- Declines in 1 hour: 8 per fingerprint
- Lockout: 90 seconds on the first trip, escalating to 15 minutes, 1 hour, and 24 hours for repeat offenders
- Event retention: 48 hours (this is also how long a device’s strikes count)
- VIP customer bypass: on
- Browser Challenge: off until you add Cloudflare Turnstile keys and turn it on
No setup is required to start protecting checkout. From activation onward, every checkout submission passes through the velocity check.
The Request Gate #
Card-Testing Defense plugs into TrustLens’s unified Request Gate — a single rule-registration surface that intercepts the classic checkout, the Blocks / Store API checkout, and the pay-for-order page. For each checkout submission the gate runs, in order:
- Users who can manage WooCommerce (admins, shop managers) skip the gate entirely
- Pro allowlists: an allowlisted fingerprint or IP passes without any further checks
- Browser Challenge (when turned on): a submission that needs a challenge and has no valid Turnstile token is rejected
- Card-testing velocity: Panic Freeze check, then VIP bypass, then held-fingerprint check, then the velocity thresholds
- Blocked-customer check (when Enable Blocking is on in Settings → General)
If a rule rejects the submission, the shopper gets that rule’s message before the payment gateway is called — for example “Too many attempts. Please wait a moment before trying again.” for a held device. If all rules pass, the request proceeds to the gateway as normal.
The gate’s design means a single code path handles all checkout enforcement — blocked customers and card-testing lockouts use the same mechanism, and adding rules (custom or future) is a plugin-level extension point.
When to Read Each Detail Page #
| Read This Page | If You Want To |
|---|---|
| Velocity Thresholds | Understand or tune the 60-second and 1-hour thresholds and the lockout ladder |
| Panic Button | Know when and how to use the emergency stop |
| VIP Bypass | Understand the false-positive prevention |
| Fingerprinting | Know what TrustLens uses to identify devices |
| Auto-Escalation (Pro) | Understand automated Panic Freeze triggers |
| Geo-Diversity Safeguard (Pro) | Avoid false-escalating on legitimate viral traffic |
| Allowlists (Pro) | Exclude QA, partners, known devices |
| Attack History (Pro) | Review the 24-hour intelligence after an attack |
If You’re Reading This During an Active Attack #
If you’re investigating an active attack right now:
- Engage Panic Freeze. Go to TrustLens → Card-Testing Defense, pick a duration, and click Engage. You have your chosen window (5–30 minutes) to investigate without further damage.
- Check the Card-Testing Defense page for the 24-hour declines, decline rate, and the Targeted now list of held fingerprints.
- If you’re on Pro, the 24-hour intelligence card gives you the hourly timeline, decline-code breakdown, and top attacking fingerprints.
- Tune velocity thresholds down if appropriate — for a slow, paced attack, lower Declines in 1 hour. If each attempt arrives from a new identity, set up the Browser Challenge and set it to Every checkout while the attack lasts.
- Deactivate the freeze when you’re ready to resume checkout.
Updated on October 18, 2026
