Free Trial Abuse: How Fake Signups Quietly Corrupt Your Conversion and Churn Numbers

Most SaaS teams have a folder of internal jokes about free trial abusers — the same three people signing up for the fourth time this month with a Gmail alias, the API key that gets rate-limited and reappears an hour later under a new account. It gets shrugged off as background noise, a cost of doing business with a self-serve signup flow. What doesn't get shrugged off nearly as often is what that noise does to your numbers once it's sitting inside your trial-to-paid rate and your churn report, indistinguishable from real prospects and real customers.

It's not a fraud problem until it's a measurement problem

Chargeback fraud is easy to categorize — someone stole a card, made a purchase, the real cardholder disputes it, you eat the loss and move on. Free trial abuse doesn't work that way, because nothing about it looks like fraud from inside your product analytics. The person signing up is a real human, using a real (if sometimes prepaid or virtual) card, going through your normal onboarding flow. The only thing that's fake is the intent. Stripe's own research groups this under "first-party fraud" specifically because the account holder themselves is the one exploiting the terms, not impersonating someone else.

That distinction is why it hides so well. A trial abuser who never converts looks, in your trial-to-paid conversion dashboard, exactly like a legitimate prospect who tried your product and decided it wasn't for them. Both show up as "trial started, never converted." One of them was never going to convert under any circumstances, and averaging them into the same denominator understates how good your product actually is at converting people who could realistically become customers.

It gets worse when the abuser does convert. A common pattern — documented in Stripe's own guidance on the topic — is a card that authorizes a small verification charge cleanly but is expected to decline on the real subscription amount two or three weeks later: a prepaid card loaded with just enough balance to pass the initial check, or a virtual card issued with a hard spend cap. When that charge fails at the end of the trial, it lands in your churn report as involuntary churn, the same bucket as a subscriber whose card expired or whose bank blocked a legitimate renewal. Our involuntary churn guide treats that bucket as recoverable with better dunning — and for real card failures, it is. For a card that was never going to clear, no amount of Smart Retries or reminder emails changes the outcome, and treating the two as one number means your recovery rate looks worse than your actual dunning setup deserves.

Telling an abuser apart from a real non-converter or a cycler

We've written before about subscription cyclers — real customers who cancel and resubscribe on a budget rhythm. Trial abuse looks superficially similar (an account appears, then disappears) but the underlying signals point in opposite directions:

No single column is definitive on its own — plenty of legitimate customers use a prepaid card, and plenty of legitimate trials get abandoned right before a usage cap. The signal is in the combination, and specifically in whether the same device or card keeps reappearing across accounts that otherwise look unrelated.

Why this accelerated specifically in AI-adjacent SaaS

Trial abuse isn't new, but it's growing unevenly. Products that give a trial user direct, metered access to something expensive — GPU time, LLM tokens, per-call API costs — are a much better abuse target than a typical SaaS trial, because the abuser is extracting real, immediate value rather than just delaying a decision to pay.

If your product isn't AI-adjacent, this doesn't mean you're exempt — it means your abuse rate is probably lower in absolute terms, but the measurement distortion works exactly the same way at smaller scale. Any product with an opt-out trial (no card required to start, as covered in our trial conversion benchmarks guide) or a generous opt-in trial with a low-friction card check is carrying some baseline rate of this, whether or not anyone's gone looking for it.

What Stripe changed, and what it doesn't cover

Stripe's research splits first-party fraud into three growing categories: account abuse at signup, free trial abuse during evaluation, and refund abuse after the customer has already gotten value. Radar's free trial abuse control, built on top of this research, scores a trial signup before access is granted and — according to Stripe — predicts violations of common trial terms, like repeated signups or a card that's unlikely to convert, with roughly 90% accuracy. It layers three kinds of signal: payment method risk (card BIN, prepaid/virtual card detection, whether a small authorization charge is likely to be followed by a real one clearing), device fingerprinting (canvas rendering, fonts, timezone, and other attributes that persist even through cleared cookies or incognito mode), and behavioral signals (the same card or device reused across multiple recent signups, or a mismatch between the card's issuing country and the signup's IP).

What it doesn't do is retroactively clean up your historical metrics, or tell your BI dashboard which of last quarter's non-converting trials or involuntary cancellations were abuse rather than genuine churn. That part is still on you, and it's worth doing even if you're not running Radar's specific control, because the underlying signals — card type, device reuse, IP/card mismatch — are things most billing stacks already have the raw data for.

Building the same checks without relying solely on Radar

If you're not ready to turn on a dedicated fraud product, three checks catch a meaningful share of trial abuse on their own:

• Rate-limit trials per card and per device, not just per email. Email is the easiest identifier to fake. A card fingerprint or a device signature is much harder to rotate, and both are available to you at signup regardless of what payment processor or fraud tooling you run.
• Flag — don't necessarily block — prepaid and virtual card BINs on card-required trials. Plenty of legitimate customers pay with prepaid or virtual cards, especially outside the US, so an outright block costs you real signups. Flagging them for a lighter-weight secondary check (a short delay before full access, or excluding them from certain usage-heavy features until the trial converts) catches most of the abuse without the false-positive cost of a hard block.
• Track same-day signup-to-cancellation ratio by acquisition channel. A channel with an unusually high rate of accounts that hit the trial's usage cap and vanish the same day is a strong early signal, well before it shows up as a dent in your blended conversion rate.

Cleaning it out of your reported numbers

The fix isn't to silently exclude suspected abuse from your metrics — that just trades one distortion for another, and it's easy to convince yourself a real problem is fraud once you have a "not counted" bucket to put it in. The fix is to tag it separately and report both numbers.

Once you have that split, run both versions through your churn calculator and compare them. If the gap between your headline churn rate and your abuse-adjusted churn rate is small, this was never costing you much beyond the raw compute or support time given away. If it's not small, you've been misreading how good your dunning recovery actually is, and possibly under-crediting a channel that converts perfectly well once the fake signups are removed from its denominator.

None of this touches the moment a real subscriber decides to leave — that's still a product, price, or fit problem, the kind our guide to why customers actually cancel is built around, and it's the moment CancelFlow's cancellation flow is designed to catch with the right offer. But a save rate and a churn number built on top of a denominator padded with people who were never going to pay in the first place isn't a number worth optimizing against. Get the abuse out of the count before you start tuning what happens at the cancel button.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.