Card Testing on Card Save Endpoints: The Attack That Never Reaches Checkout

The quiet endpoint is the target

Most stores watch the checkout page for fraud, and for good reason. It is where money changes hands. But the card save form, the wallet page, the add a payment method screen, sits one step earlier, and it is quieter in two ways that matter to an attacker. First, a validation during card setup does not usually appear on the cardholder's statement, so the card owner never notices and never reports it. Second, the form asks for less: a card number, an expiry, and a code, with no cart, no shipping address, and no order to complete. Stripe's card testing guidance states this plainly. Card setup is the method fraudulent actors prefer, because the check is invisible to the person whose card it is.

The mechanics are simple, which is why the attack scales. The attacker has a list of stolen card numbers, bought or scraped, and needs to know which ones are still live. They send each number through your save-card endpoint and watch the response. An approval, or even a decline with a specific reason code, tells them the card is real. The Federal Trade Commission counted more than 500,000 cases of credit card fraud reported in the first three quarters of 2025, nearly 180,000 more than the same period in 2024, and card testing is one of the most common entry points, because a validated card is worth far more than an untested one.

How you find out, and what it costs

You usually find out from your payment provider, not from your own logs, because the attempts never create an order. The signs are a sharp rise in failed authorizations, many distinct card numbers from a small set of IPs or devices, and attempts that skip your cart entirely and hit the payment endpoint directly. The requests often use disposable email addresses and rotate IP, browser fingerprint, or card every few attempts. One guide to diagnosing these attacks notes that if attempts appear in Stripe but not in any plugin's order log, the attacker is calling the payment API directly using your publishable key, which they scraped once from your page HTML.

The cost is not the successful charge. It is everything around it. Stripe charges roughly two cents per Radar review on blocked card testing attempts, so a 10,000 attempt overnight run costs about 200 dollars nobody planned to spend. Every declined attempt also drags down your authorization rate, which card networks watch, and the validated cards come back later as chargebacks at a different merchant, months after the testing happened. Card testing is a leading indicator of a broader fraud attack, and the actual fraud often does not occur or get detected until months later.

Three layers, in order

The cheapest defense is a server-side rate limit on the payment endpoint that never reaches your provider: a handful of attempts per IP in a short window, and no payment attempt without a cart and a session. That costs nothing per attempt and takes effect immediately. The second layer is Radar rules in Stripe, such as blocking when one IP presents more than three distinct cards in an hour, or when declined charges per card number pass a small threshold. The third is 3-D Secure on risky requests, which pushes authentication to the issuing bank. No single layer is enough, because a server limit can be worked around by rotating IPs and Radar rules only act once the payment request is in. Together they make testing impractical while leaving real customers alone, which is the point: a legitimate customer saves one card, once, from a device they own. A card tester saves hundreds, from everywhere. If the checkout page itself is the worry, the one-dollar charge that is not a sale covers card testing at checkout, and 3-D Secure 2: the friction that costs less than the chargeback covers the tradeoff on the authentication step.