Stripe Card Testing Attack: Signals and Controls

What a Stripe card testing attack is

A card testing attack sends many small charges to a payment endpoint to find out which card numbers still work. The attacker holds the numbers but not the card status. A charge that approves marks the card as live. A decline with the code stolen_card or pickup_card marks it as dead. One operator can test thousands of numbers in an hour.

Stripe is a common target because its Payment Intents API accepts card data through a server call or a hosted page, and a charge can be created in under a second. Radar scores each attempt, but a $0.50 charge from a new device often scores below the block threshold.

Signals in Stripe data

• A decline spike from one IP address or one device fingerprint.
• Many payment intents from one email with different card numbers.
• Authorization amounts from $0.00 to $1.00.
• Decline codes such as generic_decline, do_not_honor, or incorrect_cvc repeated in a short window.
• Radar risk scores clustered under the account block threshold.
• Cards used seconds apart on the same session.

What the attack costs a merchant

Every approved test charge is a live authorization. The cardholder may not notice $1.00, then disputes the larger charge that follows. Stripe charges a $15 dispute fee for each contested payment. Card networks add their own fees on top. Visa and Mastercard both run monitoring programs that fine acquirers and merchants when fraud or dispute ratios pass set thresholds. Visa replaced its Fraud Monitoring Program with the Acquirer Monitoring Program in April 2025. A merchant that stays over the threshold pays a penalty per transaction and can lose card acceptance.

Controls inside Stripe

• Radar default rules. Stripe turns Radar on for every account and blocks cards with a network fraud history.
• Custom Radar rules. Block by country, IP, card fingerprint count, or velocity inside a time window.
• Allow and block lists. Add an IP or card fingerprint after a confirmed attack.
• Checkout bot protection. Stripe Checkout can require hCaptcha before the page loads.
• 3D Secure. Requesting 3DS shifts fraud chargeback liability to the issuer in most cases.

Controls outside Stripe

• Require CVC and postal code checks on every charge.
• Set a minimum charge amount. A $1.00 floor removes most test traffic.
• Rate limit at the edge, before the request reaches Stripe. Count attempts per IP, per session, and per card fingerprint.
• Log IP, device fingerprint, user agent, and the interval between payment intents.
• Send high-velocity attempts to manual review instead of approving.

Steps after an attack

1. Export the payment intents from the attack window in the Stripe dashboard.
2. Find the shared IP addresses, card fingerprints, and email patterns.
3. Add them to the Radar block list.
4. Raise the Radar risk threshold on the affected endpoint.
5. Refund the test charges before the cardholder disputes them.
6. File a report with the FBI Internet Crime Complaint Center if the volume is large.