Can Stripe Radar Stop Free-Trial Abuse?

If you run on Stripe and your free trial is being abused, Radar is the obvious first place to look. It’s already on, it already scores your payments, and it has a rules editor. So can it stop the same person from taking your trial five times?

Mostly, no. Not because Radar is weak, but because trial abuse isn’t the problem it was designed for. This post explains where the boundary is and what fills the gap.

What Radar is built to answer

Radar’s question is: is this payment fraudulent? It looks at card activity flowing through Stripe and helps you decide whether to accept a charge, send it to review, or block it. That’s exactly what you want for:

• Stolen cards used to buy something or start a paid plan.
• Card testing, where a script runs many small authorizations to find live cards.
• Payments that later turn into disputes.

Those are real costs, and Radar is the right tool for them. If you sell subscriptions on Stripe, keep it on. Card testing at checkout covers that side in more detail.

Why trial abuse slips past

Trial abuse asks a different question: has this person already had a trial? The person usually isn’t committing payment fraud at all. Three common setups show the gap.

No-card trials

Many SaaS products start trials without collecting a payment method, because asking for a card up front lowers signups. Stripe Checkout supports this directly. In that setup, the trial begins before any payment exists. There’s nothing for Radar to score until conversion, and an abuser never converts. They take the trial, let it lapse, and sign up again with a new email.

Card-required trials with fresh cards

When the trial does collect a card, abusers rotate cards. Virtual card services, prepaid cards, a partner’s card, a second bank. Each card is real, belongs to a real person, and authorizes fine. Radar sees a legitimate card with a normal pattern. It isn’t wrong; the payment isn’t fraudulent. The abuse is in the repetition.

Same card, new account

This is the one case Stripe data can catch. Stripe exposes a card fingerprint on payment methods that stays the same for the same card number across customers. Storing it and refusing a second trial on the same fingerprint stops people who reuse one card. It’s worth doing. It just stops the laziest version of the abuse.

What actually identifies the repeat

What a returning trialist changes is cheap: email, card, IP, cookies. What they rarely change is the device they’re signing up from. A device identifier that survives cleared cookies and private windows turns “a new trial signup” into “the third trial from this browser this month,” with no card involved.

That check belongs at account creation, before Stripe is involved:

// signup handler, after the browser sent its Prynt requestId
import { PryntServer } from '@prynt/node';
const prynt = new PryntServer({ secretKey: process.env.PRYNT_SECRET_KEY });

const event = await prynt.getEvent(requestId);
const priorAccounts = event.accountsOnDevice.count;

if (event.decision === 'block') return refuse('blocked');

// a trial was already taken on this device: no trial, straight to a paid plan
const trialEligible = priorAccounts === 0;
const user = await createUser(form, { trial: trialEligible });
await prynt.updateEvent(requestId, { linkedId: String(user.id) });

const session = await stripe.checkout.sessions.create({
  /* subscription for user; add a trial period only when trialEligible */
});

accountsOnDevice lists every account you’ve attached to the device with updateEvent. The PUT /v1/events/{requestId} call after signup is what lets the next attempt see this one, so it runs for every account you create, with or without a trial.

Note the response in that example: a returning device isn’t refused, it’s offered the product without the free period. That’s often the best answer. The person clearly wants the product; they just don’t get a second trial.

How the two layers fit together

Question	Answered by	When
Is this a bot or automation hitting signup?	Device check (decision, bot signals)	Signup
Did this device already have a trial?	Device check (accountsOnDevice)	Signup
Is this the same card as a previous trial?	Stripe card fingerprint	Checkout
Is this card stolen or being tested?	Radar	Checkout and charges
Will this payment be disputed?	Radar	Charges

The device layer runs first and decides who gets a trial. Radar runs at checkout and decides whether the payment is good. Neither replaces the other.

Linking Stripe customers to devices

It’s useful to store the Prynt visitorId on the Stripe customer’s metadata when you create it. When a dispute or an early fraud warning arrives later, you can look up every account on that device and decide whether this was one bad payment or a ring. On the Scale plan, Prynt webhooks such as decision.block and risk.high can feed the same review queue as your Stripe events.

You can also report the outcome back. When a chargeback lands, POST /v1/outcomes with the label chargeback and the original requestId marks the device and the account, so on plans with Smart Signals their next visit carries the KNOWN_ABUSER reason code. Subscription billing fraud goes deeper on chargebacks and renewals.

The short answer

Radar stops bad payments. It doesn’t remember who had a trial, and it can’t see trials that never touch a card. Keep Radar on, dedupe on card fingerprint because it’s cheap, and add a device check at signup for the part neither covers. Stopping trial farming has the full playbook, and if you’re not on Stripe at all, trial abuse without Stripe covers the other billing stacks. The Free plan on the pricing page is enough to run the signup check in flag-only mode and see how many repeat devices you have.