Card testing and card cracking: what to watch for at checkout

Card cracking is an automated attack that brute forces the missing values of a payment card, such as expiry date or security code, through your own checkout or payment API. Attackers use your flow as an oracle. Signs are bursts of small attempts, many declines and one endpoint hit from many sources.

What OWASP says it is

OWASP lists card cracking (OAT-010) among its automated threats. It describes an attacker brute forcing payment card processes to find missing values: start date, expiry date or the card security code. With those and the card number, the attacker can move on to validating the card and cashing out. OWASP also uses the names card brute forcing and PAN enumeration.

OWASP's page points to related weaknesses: improper control of interaction frequency (CWE-799), improper enforcement of a single, unique action (CWE-837) and insufficient anti-automation (WASC-21). Those are the right places to look for controls. The page does not itself list countermeasures, so the steps below are engineering practice, not OWASP text.

Signals in your logs

• Many authorization attempts with a small amount, often below what a human would buy.
• The same card number with varying expiry or security code values.
• Many different card numbers from one device, IP range or session.
• A sudden rise in declines with a specific decline reason.
• Heavy traffic to the payment endpoint with little browsing before it.

Your acquirer and processor may also warn you. Their fees and dispute ratios can suffer long before your own dashboards show a problem.

Controls worth adding

1. Rate limit by several keys: IP, session, account, device and card fingerprint. A single key is easy to rotate.
2. Cap failures per card and per session, then slow down or block.
3. Require authentication for saved card flows and keep the guest checkout path as narrow as possible.
4. Add challenge steps when risk signals rise, using your provider's risk tools and 3-D Secure where available.
5. Do not leak detail in errors. Different messages for wrong expiry and wrong code tell the attacker which value to adjust.
6. Alert on decline rate with a threshold that pages a person.
7. Protect the page. Bots love unprotected endpoints, so apply bot controls to the payment API and not only the HTML page.

Where this connects to PCI

Throttling does not reduce PCI scope by itself, but weak checkout controls can make a breach or a fraud event harder to explain to an assessor and an acquirer. Keep rate limit settings and alert rules as evidence.

Try it yourself

Click through it at your own pace, or open it full screen.

Look at how a scan reports unauthenticated endpoints, since payment endpoints reachable without limits are the usual target.

Quick check

Sources

• OWASP Automated Threats: OAT-010 Card Cracking

Last reviewed: 19 October 2026.