A card enumeration attack is an automated attempt to find valid payment card details by submitting many card numbers, expiry dates, or CVV values to a payment form or API. It works when the system leaks a difference between valid and invalid data, or when weak rate limits let attackers test card data at scale.
How card enumeration attacks work
Attackers often target checkout pages, account update forms, gift card activation, and subscription endpoints. They send many low-value requests and watch for responses that suggest a card is valid. Some attacks focus on card numbers and BIN ranges; others test expiry dates or CVV values. The common thread is automation and repetition.
Card enumeration is related to card testing and BIN attacks. A BIN attack uses known issuer identification number ranges to generate candidate card numbers. Enumeration then checks which candidates work. Even a small success rate can be valuable to criminals, so merchants see many small declines and occasional approvals.
Warning signs merchants should watch
- A sudden rise in declined transactions from the same IP address, device, or customer account.
- Many attempts across sequential or similar card numbers.
- Unusually low order values, rapid repeat checkouts, or failed CVV checks.
- Traffic spikes on payment forms without matching spikes in normal browsing.
- Chargebacks or refund requests that cluster around a short time window.
Controls that reduce card enumeration risk
No single control stops every card enumeration attack. Use layered defenses and review them as attack patterns change.
- Apply velocity limits by IP address, device, customer account, BIN, and card fingerprint.
- Return generic error messages so responses do not reveal whether a card number, expiry date, or CVV was correct.
- Use CAPTCHA or other bot challenges on high-risk forms after repeated failures.
- Enable fraud tools from your payment processor and review rules for card testing patterns.
- Require strong customer authentication where available, such as 3-D Secure, to add issuer-side risk checks.
- Tokenize card data and avoid storing sensitive authentication data after authorization.
- Monitor declines, chargebacks, refunds, and average order value for sudden changes.
What to do during a suspected attack
Act fast and coordinate with your payment provider. Keep evidence in a form that does not expose full card data.
- Raise velocity limits and block obvious abusive sources at the edge or payment gateway.
- Contact your payment processor or acquirer and follow their incident guidance.
- Preserve logs, timestamps, IP addresses, device signals, and request metadata that do not contain full card data.
- Review affected accounts and orders for fraud, refunds, and chargebacks.
- Patch forms and APIs so valid and invalid responses look the same to unauthenticated users.
Why CVV data needs special handling
CVV values are sensitive authentication data. Under PCI DSS, merchants should not store CVV after authorization. If a checkout flow asks for CVV, it should send the value to the payment processor and keep it out of application logs, databases, and analytics. This limits the damage if an attacker probes your system and reduces compliance risk.
Monitoring after the attack
Card enumeration attacks often return. Watch for repeat patterns, keep fraud rules current, and test your checkout responses to confirm that card validation results are not exposed. A short incident review can show which controls failed and which should become permanent.