Card Testing False Positives

Card-Testing Defense occasionally locks out legitimate customers — typically those who fumble their credit card information enough times to trip the velocity threshold. This page covers how to identify false positives, reduce their frequency without weakening real protection, and respond when they happen.

---

What a False Positive Looks Like #

• A customer reports “I tried to check out but kept getting an error” (the lockout message reads “Too many attempts. Please wait a moment before trying again.”)
• Their device appears in Card-Testing Defense’s “Targeted now” list, having hit the velocity threshold
• The customer’s email matches a known-good customer record
• The decline codes are typical user errors (invalid expiry, insufficient funds on first card before they switched)

Distinguish from a real attack:

• Real attacks: many cards tried sequentially, all with different decline reasons
• False positives: 3–5 attempts from a normal fingerprint, often the same card with different correction attempts

---

Step 1: Identify the Affected Customer #

If a customer reports a checkout issue:

1. Ask for the date and approximate time of their attempt
2. Open TrustLens → Card-Testing Defense
3. Check the Targeted now list — each held fingerprint shows when its lockout ends and how many times it has tripped detection
4. Pro: the 24-hour intelligence panel shows the hourly timeline, decline codes and top attacking fingerprints for the last 24 hours

If you find a lockout matching their report, it’s a confirmed false positive.

---

Step 2: Restore Their Checkout Access #

A first lockout is short — 90 seconds — so by the time the customer contacts support, they may already be unblocked. A device that trips detection again is held longer: 15 minutes on the second trip, 1 hour on the third, 24 hours from the fourth. To verify or manually clear:

1. The lockout state is keyed by fingerprint hash with an expiry
2. It auto-clears when the expiry passes
3. To clear it now, click Release next to the fingerprint in the Targeted now list

Practical response: for a first lockout, tell the customer to wait 2 minutes and retry. Almost always works. For a longer hold, release the fingerprint.

---

Step 3: Prevent Future False Positives for This Customer #

Option A: Allowlist the Customer #

If the customer is genuinely valuable and you trust them:

1. Open their customer detail page
2. Click Add to allowlist
3. VIP Customer Bypass (on by default) then skips velocity checks for them — provided they also have at least the Full-confidence Order Threshold of orders (default 3)

Option B: Add the Fingerprint to the Allowlist (Pro) #

If you want to allow that specific device without committing to allowlisting the customer entirely:

1. TrustLens → Card-Testing Defense → Allowlists (Pro) → Fingerprints
2. Paste the fingerprint hash and click Add
3. Keep your own record of whose device it is — the allowlist has no label field

Option C: Add an IP Range (Pro) #

For corporate / office customers whose IPs are stable:

1. TrustLens → Card-Testing Defense → Allowlists (Pro) → IP ranges
2. Add the CIDR range (or a single IP)
3. Caution: don’t add overly-broad ranges that include attackers

---

Step 4: Diagnose If False Positives Are Common #

If many customers report checkout errors:

1. Open TrustLens → Card-Testing Defense (Pro adds the 24-hour intelligence panel)
2. Look at the held fingerprints, the decline rate and — in Pro — the hourly timeline for the last 24 hours (velocity events are kept for 48 hours by default, adjustable up to 7 days under Event retention)
3. Cross-reference against customer-complaint volume

If lockout volume is high and customer complaints are also high, you have a configuration issue, not a real attack. Common patterns:

• Velocity thresholds tuned too aggressively for your gateway behavior
• VIP bypass disabled when it should be on
• Gateway producing legitimate decline noise that hits velocity

---

Step 5: Raise Velocity Thresholds #

If thresholds are too tight:

1. TrustLens → Card-Testing Defense → Detection Settings
2. Raise Declines in 60s (e.g. 3 → 5)
3. Raise Submissions in 60s (e.g. 10 → 15)
4. If needed, raise Declines in 1 hour (default 8)
5. Save

This reduces false positives but also reduces sensitivity to real attacks. Find the right balance for your gateway and customer base.

---

Step 6: Verify VIP Bypass #

If established customers are being false-positived, VIP bypass may have been turned off:

1. TrustLens → Card-Testing Defense → Detection Settings → VIP customer bypass
2. Confirm it’s on
3. Save if changed

Despite the name, the bypass isn’t tied to the VIP segment: it covers any customer with at least the Full-confidence Order Threshold of orders (default 3) who isn’t in the Risk or Critical segment. If such a customer still hits the velocity check, bypass is off, they have fewer orders than the threshold, or they checked out with a different email. Panic Freeze blocks everyone, bypass included.

---

Step 7: Investigate Gateway Noise #

Some gateways produce decline noise that isn’t really user error:

• Stripe: Usually clean; declines are real
• PayPal: Can produce repeated declines on connection issues
• Authorize.net: Some configurations retry transparently on failure, producing decline storms
• Custom gateways: Vary widely

If your gateway is the issue:

• Configure the gateway to not retry transparently
• Raise velocity thresholds to accommodate gateway noise
• Move to a more reliable gateway

---

Step 8: Consider the Decline Codes #

The Decline codes breakdown in Pro’s 24-hour intelligence panel tells you the type of declines you’re seeing:

• Mostly “insufficient funds”: Real customers trying different cards. Velocity is sensitive; consider raising.
• Mostly “invalid expiry”: Real customers fumbling card data. Velocity sensitive; consider raising.
• Mostly “fraud suspect” / “do not honor”: Likely real card testing. Velocity correctly calibrated.
• Mostly “processor decline” / “communication error”: Gateway issue, not card-testing. Address upstream.

---

Step 9: Geographic Distribution #

If most legitimate customers come from one country but lockouts span many countries, lockouts are likely catching attack traffic — not false positives. Conversely, if lockouts are clustered in the same country as your customer base, false positives are more likely.

---

Common Patterns of Real False Positives #

• B2B customers using corporate cards: Stored cards with expired data, multiple attempts to update at checkout
• Older customers using cards they remember imperfectly: Multiple attempts to recall the expiry date
• Customers with declined cards switching to alternates: First card declines for legitimate reasons (over limit), customer tries second/third card
• Customers with browser autofill quirks: Autofill populates wrong data, declines, customer corrects

These all look like 3–5 decline attempts from a single fingerprint — similar to early-stage card testing. The distinguishing feature is usually decline-code distribution (varied codes) and post-attempt behavior (eventually succeeds with one card).

---

Long-Term Mitigation #

• Allowlist your top customers proactively (don’t wait for a false positive incident)
• Keep VIP bypass on
• Tune thresholds to your gateway’s noise level
• Monitor lockout volume vs customer complaint volume monthly
• Use the Pro fingerprint allowlist for known-good devices that produce legitimate high velocity

---

Communicating With a Falsely-Blocked Customer #

Customer complains about checkout error. Suggested response:

“Apologies for the trouble. Our payment system has automated security checks that occasionally flag legitimate customers. Please try again in a few minutes — the temporary block clears automatically. If you continue to have issues, please reply and we’ll look into it personally.”

Don’t reveal the technical details (velocity thresholds, fingerprinting). Customers don’t need that information; bad actors do.