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 Card Testing event log shows their fingerprint hitting 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
3. Look at recent decline events around that time
4. Identify the fingerprint and lockout record

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

---

Step 2: Restore Their Checkout Access #

The lockout is short — 60 seconds by default — so by the time the customer contacts support, they may already be unblocked. But if you want 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. Manually clearing requires database access or admin tooling

Practical response: tell the customer to wait 2 minutes and retry. Almost always works.

---

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 Allowlist
3. VIP bypass (on by default) means they’ll skip velocity checks from now on

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. Pro → Card Testing → Allowlists → Fingerprints
2. Add the fingerprint hash
3. Label it appropriately (“VIP customer’s home laptop”)

Option C: Add an IP Range (Pro) #

For corporate / office customers whose IPs are stable:

1. Pro → Card Testing → Allowlists → IP Ranges
2. Add the CIDR range
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 Pro Attack History tab (or Card Testing for Free)
2. Look at total lockouts per day over the past 2 weeks
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. Settings → Modules → Card Testing
2. Raise the 60-second decline threshold (e.g. 3 → 5)
3. Raise the 60-second submission threshold (e.g. 10 → 15)
4. 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 VIPs are being false-positived, VIP bypass may have been turned off:

1. Settings → Modules → Card Testing → VIP Customer Bypass
2. Confirm it’s on
3. Save if changed

VIPs should never hit the velocity check. If they are, bypass is misconfigured or the customer isn’t in the VIP segment despite expectations.

---

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-code distribution in Pro’s Attack History 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 Pro per-fingerprint overrides 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.