How to stop free trial abuse

What it costs you

• trending_downCompute, storage and per-seat vendor costs you are paying to serve somebody with no intention of converting, which is real cash rather than opportunity cost.
• trending_downExpensive resources specifically: model inference, rendering, transcoding, egress. Modern trials are far more costly to serve than a seat in a CRM ever was.
• trending_downYour trial-to-paid conversion rate, which is a number people make roadmap and pricing decisions from, distorted by users who were never candidates.
• trending_downSupport and onboarding effort spent on accounts that recur forever and convert never.
• trending_downThe trial itself, eventually, because the usual reaction is to shorten or gate it, and that cost lands on genuine evaluators.

How the attack runs

1. 01

   Establish that the trial is worth cycling

   The abuse only makes sense when the trial delivers the whole product's value in the trial window. Anything whose value compounds over time (accumulated data, team collaboration, integrations) is naturally resistant, because starting over is genuinely painful.

2. 02

   Create a fresh identity

   A new email is enough on most services. Catch-all domains and plus-addressing make this free and unlimited, and neither leaves a trace in any per-account uniqueness check.

3. 03

   Avoid whatever was checked last time

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

4. 04

   Extract the value quickly

   Trial cyclers use the product hard and early, in a compressed burst, because they know the clock. The usage curve is very unlike an evaluator's, which starts slow and builds as they involve colleagues.

5. 05

   Repeat on the same infrastructure

   Almost nobody changes machine. The same device, browser profile and network come back, because varying those is effort and the previous 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. It is worth saying plainly, because a fraud vendor telling you that you may not have a fraud problem is not the expected order of events.

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

Ask what the second trial is actually for#

The answer determines the response.

Somebody cycling trials to keep using the product indefinitely is telling you there is demand at a price point you do not offer. That is often better answered with a genuine free tier that is generous on the cheap things and firm on the expensive ones, which converts a hostile relationship into a funnel.

Somebody cycling trials to consume something expensive, model inference, rendering, egress, is a cost problem and needs a usage ceiling more than an identity check. Meter the expensive resource per account and the incentive to cycle collapses on its own.

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

The signal that survives identity rotation#

Everything a cycler presents at signup is disposable: the email, the name, often the card. So identity-based detection is always chasing.

Behaviour is not disposable. A genuine evaluator starts slowly, explores, invites somebody else and leaves gaps between sessions because they have another job. A cycler front-loads, goes straight to the endpoints that cost you the most, and disappears the moment the value is extracted.

That curve is the same across every fresh identity, because it reflects intent rather than identifiers, and it is the thing worth building on.

Withhold the trial, do not ban the account#

The correct response 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 within those limits. If you are wrong, a genuine user sees a slightly worse offer and can email you; if you are right, you removed the thing being abused without an appeals queue or an angry post.

Hard bans on this pattern are how you lock out the second evaluator at a company that was about to buy, and the asymmetry of that mistake is severe: the fraud costs you some compute, the false positive costs you the account.

Where we sit#

We score the trial signup as an event: email identity resolution, device continuity, IP and ASN reputation, and velocity across your traffic, returning allow, review or block with the checks that fired and their weights. Because the outcome you want here is usually "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 signal is a strong complement to everything at signup, and it is the one that survives when the identity does not.

Scoring the trial start#

One call at the moment the trial begins, and the two reasons that actually 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 wire up yourself#

Two of the strongest signals on this page are not Kaidn's, and the integration is short enough to show. Your processor gives you a stable fingerprint for a card; hold 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");

Combining that with the scored verdict is what closes the pattern. Neither half is sufficient: the card catches the abuser who kept their payment details, and the device and mailbox catch the one who did not.

What to work out before buying anything#

Take your trial accounts from last quarter and calculate what an unconverted trial actually costs you to serve. If it is small, this is a metrics problem and you should fix your reporting 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.