Understanding Card Testing / Auth Scrub Attacks
Stolen card data is a commodity. Before reselling or using cards, criminals need to know which ones are still live (not yet cancelled, not flagged, with sufficient available credit). The cheapest way to find out is to push small auths through a real merchant’s checkout and watch the response codes — approvals are valid, declines are dead. This activity is called card testing, and it’s typically run by automated bots that hit a checkout page or payment API hundreds or thousands of times in a short period. The damage to the merchant is real even though the dollar amount per attempt is tiny:- Authorization, network, and gateway fees pile up — many processors charge per attempted transaction whether approved or declined.
- Chargebacks follow when legitimate cardholders discover the unauthorized charges.
- Decline ratios spike, which can trigger network compliance programs (Visa VAMP, Mastercard ECM, etc.) and put the merchant at risk of fines or termination.
- Approved test auths become real transactions that must be refunded or end up as fraud chargebacks.
How a velocity filter helps
A velocity filter sets a ceiling. For example, no more than 5 transactions in any 1-minute window. If an attacker’s bot starts pushing 50 attempts a minute, the gateway only accepts the first 5 and declines the rest. The attack doesn’t stop, but the rate of damage is capped and the abnormal pattern becomes visible quickly in reporting, giving the merchant time to investigate and respond.Important caveat: The velocity filter is a containment tool, not a prevention tool. It does not actively block card-testing attacks — the attacker’s traffic still reaches the gateway, and the attempts that fit within the threshold will still be authorized and counted. What the filter does is stop the bleed early so the merchant doesn’t wake up to thousands of failed auths and the fees that come with them.
Page Layout
The Velocity Filter page is a single form with two inputs and a submit button.Header
- Title: Velocity Filter
- Subtitle: “Set the amount of transactions that can be processed though the gateway”
- Description: “The velocity filter allows you to specify a threshold for the number of transactions that can be processed in a given time frame.”
Notes block
A reminder that reads:“If you exceed the number of transactions for the given timeframe below, your transactions will decline. Reach out to your account representative for additional support.”
Form Fields
| Field | Type | Description |
|---|---|---|
| Allow | Number input | The maximum number of transactions allowed within the selected time window. Transactions over this limit are declined. |
| How Many Minutes | Dropdown | The size of the rolling time window. Options: Per 1 Minute, Per 3 Minutes, Per 5 Minutes, Per 10 Minutes. |
- Under Allow: “Set the maximum transactions allowed within the Time Period. Transactions over this limit will be declined.”
- Under How Many Minutes: “Define the time in minutes for the Transaction Limit. Transactions exceeding the limit within this period will be declined.”
Submit
- SUBMIT FILTERS — saves the configuration. The new threshold takes effect immediately for the active MID.
Configuring the Filter
- Navigate to Settings → Fraud Prevention → Velocity Filter.
- In Allow, enter the maximum number of transactions to permit per window.
- In How Many Minutes, select the window length (1, 3, 5, or 10 minutes).
- Click SUBMIT FILTERS.
Choosing a threshold
Pick a number that comfortably exceeds your peak legitimate volume so good customers aren’t accidentally declined, but low enough that a card-testing burst gets capped quickly. A few rules of thumb:- Low-volume merchants (a handful of transactions per hour): 2-5 per 1 minute is usually safe.
- Medium-volume merchants: Look at your busiest minute over the last 90 days, then add headroom (e.g., 2x the peak).
- High-volume / flash-sale merchants: A short window like 1-3 minutes with a high allow count works better than a long window with a small allow count, because long windows can starve legitimate buyers during traffic spikes.
Preventing Card Testing Attacks (Beyond Velocity Filtering)
Because the velocity filter only contains attacks, it should be paired with measures that prevent the bot traffic from reaching the gateway in the first place. Recommended controls:- Add reCAPTCHA (or hCaptcha / Turnstile) to your checkout page. This is the single most effective control against automated card-testing bots. Google reCAPTCHA v3 runs silently in the background and scores each visitor; reCAPTCHA v2 shows the familiar “I’m not a robot” challenge. Either will stop the vast majority of unsophisticated bots before a card number ever gets submitted.
- Use Ecrypt’s Hosted Payment Page or Customer Vault tokenization instead of accepting raw card numbers on your own form. The hosted page benefits from Ecrypt’s own bot-mitigation controls.
- Require AVS and CVV on your checkout. Mismatches add friction for attackers, who often have card numbers but not full billing details. (Configure under Settings → Fraud Prevention → Security Settings.)
- Block known-bad IPs at the WAF or CDN layer. Cloudflare, AWS WAF, and similar services maintain bot-traffic signatures and let you challenge or block suspicious sources.
- Use Ecrypt’s IP Allowed list when transactions should only originate from a known set of IPs (e.g., internal POS systems or a single ecommerce host).
- Rate-limit at the application layer. Limit submissions per IP, per session, and per device fingerprint on your own checkout — don’t rely solely on the gateway’s velocity filter.
- Don’t expose your Private API key in client-side code. Public keys are designed for browser use; private keys must stay on your server. A leaked private key gives attackers a direct API path that bypasses your checkout entirely.
- Monitor decline patterns daily. A sudden spike in declines — especially from
Do Not Honor,Invalid Card Number, orExpired Cardcodes — is a strong card-testing signal. Catching it within hours instead of days dramatically limits the damage. - Set up webhook alerts for declined transactions so you’re notified in near real time when something abnormal starts.
What to Do If You’re Being Attacked
- Tighten the velocity filter immediately — set Allow to a very low number (e.g., 1) and the window to 1 minute. This nearly halts the attack.
- Rotate your API keys in case a private key is compromised. (Settings → Developer Tools → API Keys.)
- Enable IP Allowed list restrictions if your traffic should only come from known IPs.
- Add or strengthen reCAPTCHA on your checkout.
- Contact your Ecrypt account representative — they can apply additional gateway-level controls and help review the activity.
- Review and refund any approved test transactions so they don’t become chargebacks.
Tips & Best Practices
- Always set some velocity threshold — even a generous one. An unconfigured velocity filter is the difference between a contained incident and a five-figure surprise on your statement.
- Treat the velocity filter as a backstop, not a strategy. Real prevention lives upstream at your checkout (CAPTCHA, hosted payments, key hygiene).
- Revisit the threshold after seasonal changes. Black Friday, end-of-month billing runs, and product launches can all push legitimate volume above a previously safe ceiling.
- Document the configuration with your team so support staff don’t troubleshoot “mysterious declines” that are actually working as designed.
- Combine with Security Settings. Requiring CVV, AVS, and other billing fields raises the cost of each test attempt and reduces the value of your checkout as a card-validation target.
- Watch reporting after configuring. The Reporting module’s decline summaries will show whether the filter is catching anything — if you see steady decline volume at exactly your threshold, you’re likely already under attack.