Short answer

A Stripe card testing attack is an automated run of small charges against your payment endpoints using lists of stolen card numbers. The attacker sends one low-value authorization per card, reads the response, keeps the cards that approve, and drops the rest. You pay for it through authorization fees, dispute fees, chargeback ratios, and a fraud score that can put your account under review.

Signals that show up first

These appear in the Stripe Dashboard, your webhook event log, and your support inbox:

  • Failed authorization volume jumps from a handful per hour to hundreds or thousands per hour.
  • Decline reason codes cluster on the same values, such as expired card, incorrect CVC, or do not honor.
  • Charges arrive in bursts of near-identical amounts, often under two dollars.
  • Card country and IP country do not match on most of the traffic.
  • Email addresses follow a pattern, with random strings or plus-addressing.
  • Checkout sessions start and end in under a few seconds on each attempt.

Prerequisites before you start

  • Admin access to the Stripe Dashboard for the affected account.
  • Radar enabled on your account, including the paid tier if you need custom rules.
  • Webhook logging turned on for payment_intent and charge events.
  • A note of your normal hourly authorization volume so you can measure the spike.

Steps to stop the attack

  1. Open the Stripe Dashboard and filter Payments by status equals failed for the last 24 hours.
  2. Pull the list of IP addresses, card BINs, and email domains behind those attempts.
  3. Add Radar block rules for the IP addresses and BIN ranges that repeat.
  4. Set a Radar velocity rule that blocks a single card fingerprint after three failed attempts in ten minutes.
  5. Turn on CVC and postal code verification so approvals require matching data.
  6. Enable a rule that blocks charges when the card country does not match the customer IP country.
  7. Raise your minimum charge amount above the typical test value, for example to one dollar.
  8. Add a CAPTCHA or bot check to any custom payment form you host.
  9. Disable guest checkout on the affected endpoint until traffic returns to baseline.
  10. File a report with Stripe support and attach the event IDs from the spike.
  11. Refund and void any test charges that did not ship, then dispute the rest with evidence.

After the burst ends

Keep the velocity rules in place for at least two weeks. Attackers retry the same endpoints with new card lists. Review your dispute ratio each week, since card networks monitor merchants whose fraud rate climbs above threshold. If your account already carries a warning, respond to Stripe risk operations with the rule changes you made and the timestamps. Store no card data outside your processor, and keep your integration on a current API version so you inherit the latest Radar defaults.