Surviving Card Testing Attack
Card-testing attacks are loud, fast, and damaging. A bot can run thousands of authorization attempts against your gateway in minutes — costing you fees, polluting your conversion metrics, and seeding chargebacks that arrive weeks later. This walkthrough is the playbook for surviving an active attack with TrustLens, both Free and Pro tiers.
Recognizing You’re Under Attack #
Common indicators:
- Spike in declined transactions in your gateway dashboard
- Multiple decline notifications from your processor
- Decline rate suddenly 10× normal (the Card-Testing Defense page shows the 24-hour decline rate)
- Unfamiliar fingerprints in the Targeted now list on the Card-Testing Defense page, or a “Card-testing attack in progress” band on the TrustLens Dashboard
- Decline codes heavily skewed toward “insufficient funds” or “invalid expiry”
If you’re seeing this, you’re being card-tested.
Immediate Response (Free) #
Step 1: Engage Panic Freeze #
Don’t troubleshoot first. Stop the bleeding.
- Go to TrustLens → Card-Testing Defense
- In the Panic Freeze box, pick a duration (5, 15, or 30 minutes)
- Click Engage
All checkouts halt for your chosen duration (default 15 minutes), and shoppers see “Checkout is temporarily paused. Please try again shortly.” The freeze applies to every shopper, including established customers — the VIP bypass doesn’t apply during a freeze. No further damage accumulates while you investigate.
Step 2: Identify the Attack #
On the same page:
- Look at the 24-hour declines, submissions, and decline rate
- Check the Targeted now list — one fingerprint with many strikes, or many fingerprints?
- If many different fingerprints are involved, or declines are climbing while few fingerprints are held, the attack is distributed or rotating identity — that’s why you needed Panic Freeze
Step 3: Tighten Defenses (Optional) #
If the attack used a slow pace, the defaults may not have caught it in time. Temporarily tighten, in the Detection Settings card on TrustLens → Card-Testing Defense:
- Lower Declines in 60s to 2
- Lower Submissions in 60s to 6
- Lower Declines in 1 hour to 5
- Save
If each attempt comes from a fresh identity, velocity counting can’t see it. Set up the Browser Challenge on the same page (free Cloudflare Turnstile keys, Test connection, then turn it on) and set Who gets challenged to Every checkout while the attack lasts.
Step 4: Deactivate Panic Freeze When Ready #
After the attack pattern stops and you’ve tightened defenses, click Deactivate Freeze (or let the timer expire). The next few minutes are critical — if the attack resumes, freeze again and consider further hardening (Pro features described below).
Immediate Response (Pro) #
Pro adds tools that often prevent the attack from requiring a manual Panic Freeze in the first place:
Auto-Escalation #
Auto-escalation runs automatically on Pro. If 3 different fingerprints were locked out within 10 minutes and the traffic wasn’t spread across 3+ countries, Panic Freeze activated on its own for 15 minutes. Your job is to verify the freeze fired and decide whether to freeze again for longer once it ends.
24-Hour Intelligence #
Open the 24-hour intelligence card on the Card-Testing Defense page for forensic data:
- Hourly decline timeline
- Decline-code breakdown
- Top 10 attacking fingerprints
- CSV export of the raw events
This tells you the shape of the attack — bursty or sustained, one device or many.
Alerts #
If a developer has configured the card-testing alert email or Slack webhook, the attack_detected, auto_escalated, and panic_activated alerts should already be in your inbox or channel. Make sure the right people are looking.
Mid-Attack Tactics (Both Tiers) #
If a Single Fingerprint Is Dominating #
Sometimes one fingerprint is responsible for the majority of attempts. The velocity lockout should be catching it — each repeat trip holds it longer (90 seconds, 15 minutes, 1 hour, then 24 hours). If it’s evading somehow:
- (Free) Tighten the global velocity thresholds to catch it on fewer attempts, especially Declines in 1 hour
- (Pro) A developer can set a tighter per-fingerprint threshold override for it
If Many Fingerprints Are Attacking #
Distributed attack. Per-fingerprint defenses alone aren’t enough.
- Turn on the Browser Challenge and set it to Every checkout
- (Pro) Auto-escalation triggers Panic Freeze at this scale automatically
- (Free) Use manual Panic Freeze repeatedly as the attack continues
- Consider raising the firewall — if you can identify a country or IP range producing most of the traffic, block at the web-server or CDN level
If Attack Is Geographically Diverse #
Pro’s geo-diversity safeguard may have blocked auto-escalation, treating the pattern as legitimate viral traffic. Verify whether this is actually viral traffic (check your marketing — did something just go live?) or whether the safeguard misjudged it.
The safeguard has no settings, so if it misjudged an attack, engage Panic Freeze manually and turn on the Browser Challenge.
Post-Attack Cleanup #
Within 24 Hours #
- Confirm the attack has stopped — no more decline spikes
- Restore velocity thresholds to defaults if you tightened them, and set the Browser Challenge back to Suspicious checkouts only
- Review orders that completed during the attack — they could be successful card tests that found live cards
- Flag those customer records for high scrutiny
- Save a record of the attack (Pro: 24-hour intelligence → Export CSV) — velocity events are deleted after the retention window, 48 hours by default
Within 1 Week #
The dispute window is starting. Expect chargebacks 2–8 weeks later on any orders that completed during the attack with stolen cards.
- Monitor incoming disputes
- Generate Dispute Evidence Reports for orders that completed during attack windows
- Cross-reference disputed orders against your exported attack data — orders from attacking fingerprints have strong fraud evidence
Within 1 Month #
- Review your chargeback ratio — has it spiked from attack disputes? Remember that Visa’s VAMP ratio also counts fraud reports from the stolen cards, which TrustLens can’t see
- If yes, prepare for processor scrutiny; communicate proactively
- Tune defenses based on lessons learned
Preventive Setup for Next Time #
The best response is no attack at all. Configure:
| Setup | Effect |
|---|---|
| Browser Challenge configured (Free) | Stops attackers who change identity on every attempt; Suspicious checkouts only is the recommended everyday setting |
| Auto-escalation (Pro, always on) | Auto-freezes on distributed attacks |
| Geo-diversity safeguard with working WooCommerce geolocation (Pro) | Prevents auto-escalation false positives |
| Card-testing alert email / Slack webhook set (Pro) | Realtime notification when attacks start |
| VIP customer bypass left on | Established customers aren’t caught by velocity rules |
| Fingerprint and IP allowlists for QA / partners (Pro) | Reduce false-positive volume |
| Velocity thresholds tuned to your gateway behavior | Right balance of sensitivity and noise |
What to Communicate Externally #
During or after a significant attack:
- Processor: Most appreciate proactive notification. They’ve seen the spike anyway; getting your context helps.
- Customer service team: Some legitimate customers may have had failed checkouts during defensive measures. Brief CS so they can handle inquiries.
- Marketing team: If the attack coincided with a campaign, conversion data is polluted. Note for analytics review.
- Stakeholders / leadership: Document attack scale and protection effectiveness. This is the kind of incident that justifies the Pro license.
What Not to Do #
- Don’t disable Card-Testing Defense. Even partially, even temporarily. The attack will resume immediately.
- Don’t loosen thresholds to “see what’s happening.” The bot doesn’t slow down because you’re watching.
- Don’t email blocked attackers. They’re bots; emails go nowhere or to inboxes you don’t want to interact with.
- Don’t assume the attack stopped after one wave. Many bots return after a cooldown.
Metrics to Track #
- Time from attack start to first defensive action
- Total declines blocked during the attack
- Orders that completed during attack (potential fraud)
- Chargebacks attributable to the attack (track 4–8 weeks out)
- False-positive customer complaints in the week following
Updated on October 18, 2026
