How to stop free trial abuse

What it costs you

• trending_downCompute, storage and per-seat vendor fees you pay to serve someone who was never going to buy. That is real cash, not lost opportunity.
• trending_downExpensive things especially: model inference, rendering, transcoding, bandwidth. A modern trial costs far more to serve than a seat in a CRM ever did.
• trending_downYour trial-to-paid conversion rate, which people use to make roadmap and pricing decisions, now skewed by users who were never candidates.
• trending_downSupport and onboarding time spent on accounts that come back forever and buy never.
• trending_downThe trial itself, eventually. The usual reaction is to shorten or gate it, and that cost lands on the real evaluators.

How the attack runs

1. 01

   Check the trial is worth cycling

   This only makes sense when the trial gives you the whole product's value inside the trial window. Anything whose value builds up over time (accumulated data, a team working together, integrations) resists naturally, because starting over genuinely hurts.

2. 02

   Make a fresh identity

   A new email is enough on most services. A catch-all domain or a plus tag makes that free and unlimited, and neither leaves a mark in any one-per-account check.

3. 03

   Avoid whatever caught them last time

   If a card was required, a virtual card. If a phone was required, a rented number. The response is aimed precisely at the control that stopped them, which is why publishing your control is expensive.

4. 04

   Get the value out fast

   Trial cyclers use the product hard and early, in a compressed burst, because they know the clock is running. That curve looks nothing like an evaluator's, which starts slow and builds as they pull colleagues in.

5. 05

   Do it again on the same machine

   Almost nobody changes computer. The same device, browser and home network come back, because changing those is effort and the last signup was not blocked on them.

The signals that do

These are the signals that carry weight on trial abuse, and why each one is the signal rather than the obvious alternative. Not all of them are ours: the ones marked you build this genuinely work and Kaidn does not check them, so you would be wiring them up yourself. Listing those unlabelled would read as a claim we cannot support.

Trial abuse is the one pattern on this site where the right first move is usually not detection at all. Worth saying plainly, because a fraud vendor telling you that you might not have a fraud problem is not the expected order of events.

If somebody can get everything they need out of your product inside a trial, then start over freely, that is a packaging problem. No amount of scoring fixes a trial that is really a free tier with extra steps.

Ask what the second trial is for#

The answer tells you what to do.

Cycling to keep using the product forever means there is demand at a price you do not offer. That is often better answered with a real free tier: generous on the cheap things, firm on the expensive ones. It turns a hostile relationship into a funnel.

Cycling to consume something expensive (model inference, rendering, bandwidth) is a cost problem and needs a usage ceiling more than an identity check. Cap the expensive resource per account and the reason to cycle collapses on its own.

A second trial from the same company domain is usually not abuse at all. It is a colleague. Treating them as a fraudster is an expensive way to lose a deal that was already in progress.

The signal that survives a change of identity#

Everything a cycler shows you at signup is disposable. The email, the name, often the card. So identity-based detection is always one step behind.

Behaviour is not disposable. A real evaluator starts slowly, pokes around, invites somebody else, and leaves gaps between sessions because they have another job. A cycler front-loads, goes straight to whatever costs you the most, and disappears the moment they have what they came for.

That curve looks the same behind every fresh identity, because it reflects what they want rather than who they claim to be. It is the thing worth building on.

Withhold the trial, do not ban the account#

The right answer to a probable repeat trial is almost never a ban.

Decline the second trial. Offer the free tier or the paid plan. Let them keep using the product inside those limits.

If you are wrong, a real user sees a slightly worse offer and can email you. If you are right, you removed the thing being abused without creating an appeals queue or an angry post.

Hard bans here are how you lock out the second evaluator at a company that was about to buy. The asymmetry is brutal: the abuse costs you some compute, the false positive costs you the account.

Where we sit#

We score the trial signup: what the email resolves to, whether the device has been here before, IP and network reputation, and how fast the same pattern is repeating across your traffic. You get allow, review or block with the checks that fired and what each one counted for.

Because what you usually want here is "no trial" rather than "no account", the review verdict is the one to wire up first.

We do not see your usage curve unless you send it. If you can post a custom event when an account crosses a meaningful usage threshold, that pairs well with everything at signup, and it is the signal that keeps working when the identity changes.

Scoring the trial start#

One call when the trial begins, and the two reasons that really carry this pattern:

const r = await kaidn.score({
  event: "trial_start",
  user_id: user.id,
  ip: req.ip,
  email: user.email,
  device_id: body.kaidn_device_id,
});

const repeat =
  r.reasons.includes("device_reuse") || r.reasons.includes("email_reuse");

// Withhold the TRIAL, not the account. A false positive here costs a trial.
if (repeat || r.verdict !== "allow") {
  await createAccountWithoutTrial(user, r.event_id);
  return { trial: false, reason: r.reason_text };
}

return startTrial(user);

The half you build yourself#

Two of the strongest signals here are not ours, and the code is short enough to show. Your processor gives you a stable fingerprint for a card. Store it and count:

// Stripe returns a stable fingerprint for the same card across customers
const { fingerprint } = paymentMethod.card;

const priorTrials = await db.trials.count({ card_fingerprint: fingerprint });
if (priorTrials > 0) await createAccountWithoutTrial(user, "card_seen_before");

Putting that next to the scored verdict is what actually closes the pattern. Neither half is enough on its own. The card catches the abuser who kept their payment details. The device and mailbox catch the one who did not.

What to work out before buying anything#

Take last quarter's trial accounts and calculate what one unconverted trial actually costs you to serve.

If it is small, this is a reporting problem, and you should fix your metrics rather than your defences. If it is large, you now know your budget, and the first thing to spend it on is probably a usage ceiling rather than a fraud tool.