Card Testing Monitoring Procedure: Detect Test Charges Early

A card testing monitoring procedure is a scheduled review of authorization data that flags bursts of small-value declines, repeated attempts against many card numbers from one device or IP, and abnormal decline ratios per BIN. The purpose is to catch test charges within the first few attempts, block the source, and keep stolen-card traffic off your gateway. Run the checks daily at minimum, and hourly during peak sales windows.

Prerequisites

• Access to gateway authorization logs with BIN, response code, IP address, device fingerprint, and timestamp
• A rule engine or fraud dashboard that filters by decline reason and velocity
• Thirty days of clean traffic data to use as a baseline
• A named owner for alerts and a written escalation path

Signals to watch

• Low-value order clusters. Multiple orders under a few dollars, often for digital goods or gift cards, within minutes.
• Decline ratio spikes. A jump in issuer declines on a single BIN or card prefix.
• Velocity per source. Many card numbers tried from one IP, device fingerprint, or email domain.
• Sequential card numbers. Authorization attempts that differ by a few digits.
• Response code patterns. Repeated do-not-honor or incorrect-CVV codes from one session.
• Geographic mismatch. Billing country and IP country diverge across a batch of attempts.

Daily monitoring procedure

1. Pull the previous 24 hours of authorization records into your fraud dashboard.
2. Filter for orders under your low-value threshold and count them per hour.
3. Group attempts by IP, device fingerprint, and email domain, then rank by distinct card numbers tried.
4. Compare today's decline rate per BIN against the 30-day baseline.
5. Flag any source that hit more than five distinct card numbers in one hour.
6. Check the CVV and address verification response mix on flagged sessions.
7. Record every flagged source in the case log with a timestamp and the number of attempts.
8. Push confirmed sources to your blocklist and to the gateway's deny rules.

Set alert thresholds from your baseline

Do not copy thresholds from another merchant. Your normal decline rate depends on product, price point, and customer mix. Start with a threshold at three times the baseline rate for the same hour of day, then tighten it after two weeks of observation.

• Decline rate per BIN above three times baseline
• More than five card numbers from one IP within 60 minutes
• More than ten low-value orders per hour across the storefront
• Any card number attempted more than three times in a day

Respond to a suspected test run

1. Pause the source by IP, device fingerprint, and email pattern in the rule engine.
2. Require CVV and address verification on the affected payment page.
3. Rate-limit checkout attempts per session and add a challenge on the third failure.
4. Void or refund any captured test charges before settlement.
5. Notify your acquiring bank if the volume suggests a coordinated run.
6. Document the timeline, the blocked identifiers, and the dollar value of prevented charges.

Weekly and monthly review

1. Review blocked-source counts and confirm the rules still fire on new traffic.
2. Retire rules that produce false positives above an agreed rate.
3. Recompute baselines and adjust thresholds for seasonality.
4. Test the alert path end to end with a synthetic low-value order.
5. Report the trend to the team that owns chargebacks and dispute rates.

Common gaps

• Monitoring only successful charges and ignoring declines, where most test attempts appear.
• Watching IP alone while attackers rotate through proxies.
• No shared blocklist between the storefront and the gateway.
• Alerts routed to a shared inbox with no assigned owner.