Card testing attack

A card testing attack is a bot pointing a list of stolen or guessed card numbers at your public payment endpoint to find out which ones still work. The attacker does not want your product. The approval itself is the prize, and the working cards get sold or spent elsewhere. The BIN attack variant walks sequential numbers inside one issuer's range, so you see cards that look suspiciously alike.

It shows up as a spike of tiny authorizations, a decline rate that jumps from 8 percent to 80 percent overnight, and many distinct cards behind a handful of IPs, emails, or devices. Your soft targets are anything unauthenticated that touches a card: donation forms, open payment links, card-required free trials, and zero-amount card validation. Defenses that actually bite: bot detection and a challenge on the payment form, rate limits per IP, device fingerprint and email, a hard block after N failed attempts, minimum charge amounts, and processor rules (Stripe Radar and equivalents) that block the pattern.

Gotcha: the tiny charges are not the cost. Declines are rarely free: depending on your provider and contract they can carry per-attempt gateway fees, network charges for excessive authorization attempts, or penalties once the volume gets noticed, so check what your own pricing does with a failed attempt. Add dispute fees on the few that go through, and if your authorization-to-approval ratio stays bad you land in a card network monitoring program with fines, or your processor freezes payouts. Refunding the successful test charges does not cancel the chargeback that follows.