The month a card-testing attack hit my signup form at $35K MRR: a fraud diary (2026)

I crossed $35K MRR on a Tuesday in early 2026. I know the exact day because I had just turned on a public, no-friction signup: enter an email, add a card, land in the product. No credit-card-required trial gate, no waiting room. Fewer steps, more conversions. For about nine days it was the best decision I had made all year.

On the tenth morning I woke up to 1,400 emails.

The morning the graph went vertical

They were Stripe receipts and decline notifications, stacked since roughly 3am. My phone had a payments dashboard widget on the home screen, and the little sparkline that normally crawls along at a gentle slope was a straight vertical wall.

My first, hopeful thought was that something had gone viral overnight. It took about ninety seconds of scrolling to understand it was the opposite. The "customers" had names like "asdf qwerty" and email addresses that were random strings at domains I did not recognize. Almost every charge was a tiny amount. Almost every one had failed. A few had gone through.

I was not having a good sales day. I was being used as a testing tool.

What was actually happening

This was a card-testing attack, and if you have not lived through one, it is worth understanding precisely because it does not look like the fraud you expect.

Card testing (also called carding, enumeration, or account testing) is when someone with a batch of stolen or guessed card numbers runs them against a live payment form to find out which ones are still valid. Stripe has a blunt, useful writeup of the mechanics, and the key line is that fraudsters prefer to validate cards during card setup rather than on a real purchase, because setup attempts and tiny authorizations rarely show up on the real cardholder's statement (see the Stripe card-testing guide, accessed 2026). No statement line means no complaint, which means the stolen card stays useful for longer.

My open signup form was a perfect instrument for that. It saved a card. It ran an authorization. It required nothing that a script could not fake. I had optimized every point of friction out of the exact endpoint a card tester wants most.

This is not the same thing as the month a chargeback wave froze my Stripe and I had to argue with the dispute system after the fact. Chargebacks are the bill arriving late. Card testing is the break-in happening live, in the middle of the night, at a rate no human could produce. Different problem, different fix, and I had spent my worry budget preparing for the wrong one.

The bill was not the scary part

The direct cost was real but survivable. Thousands of authorization and decline attempts, and on the custom-rate pricing I was on, some of those attempts carry a fee whether they succeed or not. I burned a few hundred dollars in fees before I got it stopped. Annoying, not fatal.

The scary part was the second-order damage, and Stripe's own documentation is honest about it. A flood of declined payments pushes up your decline rate, and a high decline rate makes issuers and card networks treat all of your traffic as riskier, including your legitimate customers. It can, if it keeps up, land you in a card-network monitoring program. In plain terms: a bot could poison my reputation with the banks badly enough that real, paying, honest customers would start getting falsely declined at checkout. My $35K MRR was not threatened by the fees. It was threatened by the possibility that my payment rails would quietly start failing for the people I actually wanted.

Around 8am I got the email I had been dreading, a fraud-activity notice from Stripe flagging unusual volume on my account. It was polite. It was also the clearest "fix this now" I have ever received.

The 48 hours that followed

I am not going to pretend I responded like a security professional. I responded like a founder who had one job that day. Here is the order I did things in, which turned out to be roughly the order Stripe recommends anyway.

First, I stopped the bleeding at the door. I put a bot check on the signup form. I used Cloudflare Turnstile, which runs invisible, non-interactive challenges to tell humans from scripts without making real users solve a puzzle (per the Turnstile documentation, accessed 2026). The important detail I almost got wrong: you have to validate the token on the server, not just render the widget, or a script simply skips the page and calls your endpoint directly.

Second, I added rate limits. Stripe's guidance is specific and I copied it almost verbatim: cap how many new customers can be created from a single IP in a day, and cap how many card-add attempts a single session can make. A real person signs up once. A script wants thousands of tries. Any limit at all breaks the economics of the attack.

Third, I stopped rewarding the pattern. I refunded the handful of charges that had gone through, because refunding a suspicious card-testing charge quickly is how you avoid it coming back as a dispute later. Then I made sure my payment retry logic would not helpfully re-run the fraudulent cards, which would have re-run the whole attack for them.

Fourth, once the fire was out, I added velocity rules in Stripe Radar to block bursts of activity that look like testing rather than buying, and I put the actual "add a card" step behind a real, logged-in session instead of an anonymous public form. The frictionless signup that had felt so clever was the whole vulnerability. I traded three seconds of user friction for not being a public card-validation service.

By the second evening the wall on my sparkline was gone. I lost no customers to this directly. What I lost was the comfortable belief that "we are too small to be a target." Card-testing bots do not check your MRR. They check whether your form answers them.

What it actually cost, honestly

A few hundred dollars in fees. Two days I had earmarked for shipping a feature. And a genuinely uncomfortable week afterward watching my legitimate decline rate, waiting to see whether the bots had done lasting reputational damage with the issuers. They had not, or not enough to notice, but I did not know that for about ten days, and that not-knowing was the real tax.

The uncomfortable lesson is that this was not bad luck. It was a design decision. I had removed friction from the one endpoint where a little friction is the entire defense. Growth optimization and fraud exposure were the same knob, turned the same direction, and I had turned it without understanding what was on the other side.

The one thing I would tell past me

Put your "add a card" step behind something a script cannot cheaply pass, before you need to, not after. A bot check plus a per-IP rate limit on signup would have taken me an afternoon to add while calm. Adding them at 8am with a fraud notice in my inbox took the same afternoon, minus the calm, plus the fees. The work is identical. Only the adrenaline is optional.

Keep reading

If you want the other side of the payments-fraud coin, the slow-bleed version rather than the overnight-flood version:

• The month a chargeback wave froze my Stripe at $23K MRR, which is what happens when the bill for fraud arrives weeks late instead of live.
• The month I found 7% of my MRR leaking to failed cards, a quieter payments problem that costs more than most founders realize.