How do velocity limits stop card testing?
Card testing sends many small attempts with different card numbers from the same devices or sessions. Velocity limits count attempts per device, IP and session and block the burst before authorization requests reach issuers.
In detail
Card testing sends many small attempts with different card numbers from the same devices or sessions. Velocity limits count attempts per device, IP and session and block the burst before authorization requests reach issuers.
What card testing looks like
Fraudsters with lists of stolen or generated card numbers try them on a merchant with low friction, often with small amounts. Approved cards are then used or sold elsewhere. Signs include spikes in declines, many cards from one device or IP, and repeated small amounts.
Which limits help
- Number of distinct cards per device, IP or session.
- Failed attempts per device or session in a short window.
- Attempts per card across different merchants on the same platform.
- Rate limits on the payment page or API.
Why stopping it early matters
Each test attempt costs authorization fees, raises decline ratios and can put a merchant in scheme monitoring programs for enumeration. Blocking before authorization saves those costs.
Other defenses
CAPTCHA or bot detection on checkout, 3-D Secure for suspicious attempts, minimum amounts and alerts on decline spikes.
What it means for payment operators
For you, card testing on one merchant can spread to others. Platform-level velocity rules, with alerts on decline spikes per merchant, help you contain attacks before they reach issuers and scheme thresholds.