Card-Required vs No-Card Free Trials: Which Actually Stops Abuse?

Every SaaS team with a free trial eventually has the card argument. Growth wants no card at signup because it is the friction they can measure. Finance wants a card because trials are being farmed and compute is not free. Both are right about part of the problem, and neither option on its own does what its advocates expect.

This post looks at what a card requirement actually filters, what it costs, what a no-card trial needs in order to survive, and why the best answer for many products is a card requested only from the devices that earn it.

What a card requirement really checks

A card at signup is usually a zero-amount or small authorization. When it succeeds, you have learned that:

• the number is valid and the issuer approved the authorization;
• whoever typed it had the number, expiry and security code at that moment.

You have not learned that the person is new to your product, that they intend to pay, or that the card will still work in 14 days. That gap is where trial abuse lives.

What gets through anyway

• Prepaid cards. Bought with cash in many markets, loaded with a small balance, authorized once, then left empty.
• Virtual card numbers. Many banks and fintech apps let a customer generate a fresh card number per merchant, or a single-use one, in seconds. These features exist for good privacy reasons, and they are just as useful to someone who wants a new trial every month.
• Borrowed cards. A friend’s or relative’s card passes every check because it is a real, funded card held by a real person.

You can try to detect prepaid and virtual cards from BIN data, but the line between “virtual card used for privacy by a loyal customer” and “virtual card used for trial number nine” is invisible at the payment layer. The card tells you about the instrument, not the person or the device behind it.

What a card requirement costs

The cost is conversion. Some share of honest prospects will not hand over a card to try something, especially for developer tools, products bought by teams where the person evaluating is not the person paying, and markets where card penetration is low. How large that share is depends on your product and audience; measure it on your own funnel rather than borrowing a number from a blog post.

There are second-order costs too:

• Card-required trials tend to convert to paid automatically, which can produce refund requests and chargebacks from people who forgot to cancel.
• Card testing becomes a risk: a signup form that runs authorizations is a target for criminals validating stolen numbers. That is a payment-fraud problem you created by adding the card step, covered in our payment fraud detection overview.
• Prospects in regions where you do not support local payment methods are filtered out regardless of intent.

What a no-card trial needs

A no-card trial removes friction for everyone, abusers included. To survive, it needs some other way to notice that this signup is not new. The usual candidates fail in familiar ways:

• Email. Plus-addressing, catch-all domains and disposable inboxes make new addresses effectively free.
• IP address. Residential proxies rotate IPs cheaply, and office and university networks put many real users behind one address.
• Phone verification. Better, but virtual numbers are cheap, and SMS adds cost and delivery problems in some countries.

What abusers find hardest to rotate is the device. Clearing cookies and opening an incognito window does not change a stable device identifier. With Prynt, the signup page calls identify(), your server fetches the event for that requestId, and the response includes accountsOnDevice: every account you have linked to that device. “This device already has two trials” is a much stronger fact than anything a card or an email tells you. The full mechanics are in our guide to stopping free-trial farming.

Device limits have their own failure mode: households and shared computers. A limit of one trial per device can catch a partner using the same laptop. That is why the response to “over the limit” should usually be a verification step, not a wall.

The hybrid: ask for a card only from risky devices

You do not have to pick one policy for every visitor. A hybrid design looks like this:

Device situation	Trial requirement
No prior accounts, clean signals	No card. Start immediately
One prior account on the device	No card, but flag for review
Over your per-device limit	Card or phone verification before the trial unlocks
Prynt decision is block (automation, tampering, burned device)	No trial

Most visitors land in the first row and never see the card form. The person on their sixth trial meets a card step, and because they have used up their real cards’ goodwill, that step finally costs them something. In the server code it is one branch:

const ev = await prynt.getEvent(requestId);           // @prynt/node
const others = ev.accountsOnDevice?.count ?? 0;

let requirement = 'none';
if (ev.decision === 'block') requirement = 'deny';
else if (others >= 2) requirement = 'card';
else if (others === 1 || ev.decision === 'challenge') requirement = 'review';

After the account is created, call prynt.updateEvent(requestId, { linkedId: String(user.id) }) (the linkedId must be a string) so the next signup from that device counts it.

The same pattern works for verification steps other than cards. Some teams use a phone number, some require a work email domain, some require MFA on every login for flagged accounts. The point is that the cost lands on the repeat signup rather than on everyone.

Picking for your product

A few heuristics:

• Expensive trials (GPUs, LLM tokens, outbound email or SMS credits) can justify a card for everyone, but layer device limits on top, because virtual cards will otherwise farm you anyway.
• Cheap trials with self-serve conversion almost always do better without a card plus device limits. The abuse that remains is small and visible.
• Product-led tools for teams should avoid cards at signup. The evaluator is rarely the payer, and a card wall stops the evaluation before it starts.
• Free plans that never expire have the same problem as trials, only slower. Our post on protecting free plans covers limits that work over months instead of days.

Whatever you choose, measure it as a funnel, not a fraud metric: signups, activated trials, paid conversions and trial cost per paying customer. Our guide to protecting the signup funnel without killing conversion walks through those numbers.

A practical starting point

Run your current trial as is and add device identification in monitor mode for two weeks. Count how many trials came from devices that already had accounts, and how much those trials consumed. If that number is small, a no-card trial with flagging is enough. If it is large, start the hybrid: card or phone only for devices over the limit. The free plan on our pricing page includes 20,000 identifications a month, which is often enough to run that measurement on an early-stage signup page.