Surviving Card Testing Attack
5 min read
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
- Unfamiliar fingerprints producing many attempts in TrustLens’s Card Testing event log
- 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: Hit Panic Freeze #
Don’t troubleshoot first. Stop the bleeding.
- Go to TrustLens → Card-Testing Defense
- Click the red Panic Freeze button
- Confirm
All checkouts halt for your chosen duration (default 15 minutes). Your VIPs can still check out (bypass on by default). No further damage accumulates while you investigate.
Step 2: Identify the Attack #
On the same page:
- Look at recent decline events — what fingerprints?
- Check the velocity counters — single fingerprint hammering, or distributed?
- If distributed, the per-fingerprint lockouts aren’t catching it — that’s why you needed Panic Freeze
Step 3: Tighten Velocity Thresholds (Optional) #
If the attack used a slow pace, the defaults may not have caught it in time. Temporarily tighten:
- TrustLens → Card-Testing Defense
- Lower the 60-second decline threshold to 2
- Lower the 60-second submission threshold to 6
- Save
Step 4: Cancel Panic Freeze When Ready #
After the attack pattern stops and you’ve tightened thresholds, cancel the freeze. The next few minutes are critical — if the attack resumes, refreeze and consider further hardening (Pro features described below).
Immediate Response (Pro) #
Pro adds tools that often prevent the attack from requiring Panic Freeze in the first place:
Auto-Escalation #
If Auto-Escalation was on, Panic Freeze likely activated automatically when the attack spread across multiple fingerprints. Your job is to verify the freeze fired and decide whether to keep it active longer than the default 15 minutes.
Attack History Tab #
Open the Attack History tab for forensic data:
- 24-hour decline count
- Decline-code breakdown
- Top-10 attacking fingerprints
- Geographic distribution
This tells you the shape of the attack — bursty or sustained, single botnet or distributed.
Alerts #
If you’ve configured Slack alerts, the attack_detected, auto_escalated, and panic_button_activated notifications should already be in your 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, but if it’s evading somehow:
- (Pro) Add the fingerprint to the per-fingerprint override with a tight custom threshold
- (Free) Tighten the global velocity thresholds to catch it on fewer attempts
If Many Fingerprints Are Attacking #
Distributed attack. Per-fingerprint defenses alone aren’t enough.
- (Pro) Confirm Auto-Escalation is enabled and configured to trigger Panic Freeze on this scale
- (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 misfired.
If the safeguard misfired, temporarily disable it or lower its country threshold.
Post-Attack Cleanup #
Within 24 Hours #
- Confirm the attack has stopped — no more decline spikes
- Restore velocity thresholds to defaults if you tightened them
- Review which fingerprints completed orders during the attack — they could be successful card-testing tools that found live cards
- Flag those customer records for high scrutiny
- Generate a post-attack report (Pro Attack History → Export CSV)
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 the Attack History — orders from attacking fingerprints have strong fraud evidence
Within 1 Month #
- Review your chargeback ratio — has it spiked from attack disputes?
- 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 |
|---|---|
| Auto-Escalation enabled (Pro) | Auto-freezes on distributed attacks |
| Geo-diversity safeguard enabled (Pro) | Prevents auto-escalation false positives |
| Slack alerts configured (Pro) | Realtime notification when attacks start |
| VIP allowlist populated | Confirmed legitimate customers can’t be caught |
| Fingerprint 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 open up rate limits 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
