What Stripe card testing is

Card testing is an attacker pushing a list of stolen card numbers through a live payment form to learn which ones still authorize. On Stripe it looks like a run of small charges, a jump in declines, and new "customers" whose billing address and country do not match the card. The charges are small on purpose: a few cents to a few dollars keeps the attempt under fraud triggers and proves the card works. The attacker then sells or reuses the verified number somewhere with a bigger ticket.

more on this topic

You cannot opt out of being probed, but you can make your checkout a poor target. Stripe gives you the tools: Radar rules, rate limits, 3D Secure, and card fingerprint data. The steps below stop an active run and then harden the account so the next attempt costs the attacker more than it earns.

read more

Prerequisites

• Stripe dashboard access at administrator or developer level
• Radar enabled on the account, with rule editing available on your plan
• Ability to change checkout code, or access to Stripe-hosted page settings
• A way to read request logs for your site (server logs or an edge provider)

Confirm it is card testing, not a sales spike

Real growth brings varied amounts, returning customers, and matching geography. An attack brings repetition. Look at Payments in the dashboard, filter to declined, and sort newest first. Ten or more attempts from one IP address or one card fingerprint inside a few minutes is the signature. So is a cluster of charges under one dollar from countries you do not ship to.

stripe card testing v3

Steps to stop an active attack

1. Open the Payments list, filter by declined, and note the IP addresses, card countries, and card fingerprints that repeat.
2. In Radar, create a block rule for each offending IP or country you do not sell to.
3. Add a rate limit in your checkout so one session or IP can attempt a card only a few times per hour.
4. Turn on CAPTCHA or hCaptcha on the payment form and require it before the card field submits.
5. Enable 3D Secure for new customers and for any charge Radar scores as elevated risk.
6. Refund and cancel every small charge that did authorize, and mark each one as fraud in the dashboard.
7. Open a ticket with Stripe support, describe the pattern, and ask for a review of the processing fees on the declined run.

Radar rules that cut repeat attempts

• Block when the card country does not match the IP country.
• Block when the risk score is above 65 and the customer has no prior successful charge.
• Block when one card fingerprint attempts more than three charges in an hour.
• Block when the billing ZIP fails verification twice on the same email.
• Review, rather than block, charges from a new country on an established account so you do not lose legitimate buyers.

Settings that lower your exposure

• Require the CVC and full postal code on every card entry.
• Keep the payment form on your own domain and check that your publishable key is not reused on a scraped clone.
• Watch the dispute rate. Card networks put merchants into monitoring programs when disputes pass roughly 0.9 percent of transactions, and a testing run can push you over that line in a week.
• Review Radar's default rules each quarter, since your product mix and shipping countries change.

After the run ends

Pull a list of every charge in the window and reconcile it against your order records. Refund the ones with no matching order, label them as fraud so Radar learns, and keep the evidence in case of a dispute. Check your API logs for keys used from unknown IP addresses, and roll any key that looks exposed. Add the incident dates to a short internal note so the next review has a baseline.

more on this topic

Do not attempt to test card numbers yourself to "see what the attackers see." That traffic is indistinguishable from an attack and can get your account flagged by the same rules you just turned on.