Free-Trial Abuse in LatAm SaaS When Cards Aren't the Default

Ask a SaaS team in Mexico City, São Paulo or Bogotá how they handle free-trial abuse, and the standard advice from US playbooks doesn’t fit. “Require a card for the trial” assumes your buyers have a card they’re willing to put into a SaaS checkout. Many of yours don’t, or won’t.

So LatAm products adapt. Trials start with no payment details. Paid plans go through local rails: Pix and boleto in Brazil, OXXO and SPEI in Mexico, PSE in Colombia, wallets like Mercado Pago, or a bank transfer against an invoice. That’s the right call for conversion. It also quietly removes the one signal most trial-abuse defenses lean on.

The card was doing more than taking payment

In card-first markets, a card-required trial does double duty. It’s a payment method, and it’s an identity check. A card is moderately expensive to replace, so asking for one limits how many trials one person can take, and processors expose a card fingerprint you can dedupe on.

Take the card out and what’s left to tie two signups together?

• Email. Free and infinite. Gmail dots and plus-addressing alone give one inbox many variants.
• Phone. Better, but prepaid SIMs are cheap and virtual numbers are easy to buy. Requiring a phone also adds friction for everyone, and in some markets people share a family number.
• IP address. Mobile carriers place many subscribers behind shared addresses, and offices and coworking spaces do the same. IP limits catch real users and miss anyone with a VPN.
• Tax IDs (RFC, CPF, CUIT). Useful for B2B at conversion, but asking for one at trial signup costs you most of the people who were just curious.

None of these are stable enough for “one trial per person” when the person is motivated.

What abuse looks like without a card

The patterns are the same as anywhere; the cost of each attempt is lower.

• The serial trialist. A freelancer or small agency that uses your product continuously by opening a new trial every 14 days with a new email.
• Resold access. Someone creates trial workspaces and sells logins, common for AI tools, design tools and anything with paid credits.
• Credit farming. Scripts creating accounts to collect free API credits or generations, often through VPNs and datacenter IPs.
• Competitive scraping. A competitor opening trial after trial to export data or study features.

The device as the dedupe key

What these abusers don’t rotate cheaply is the device. The serial trialist uses the same laptop. The credit farmer runs from a few machines or a handful of phones. A device identifier that survives cleared cookies, private windows and new emails links those trials together.

With Prynt, the signup page identifies the browser and sends a requestId with the form. Your server fetches the event with your secret key and checks how many of your accounts that device already holds:

// browser — agent from https://api.pryntid.com/cdn/prynt.umd.js
const prynt = await Prynt.load({ apiKey: 'pk_live_…' });
const { requestId } = await prynt.identify({ tag: { action: 'signup' } });

// server
const event = await prynt.getEvent(requestId);      // @prynt/node
const others = event.accountsOnDevice.count;

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

const user = others >= 1
  ? await createAccount(form, { trial: false, needsVerification: true })
  : await createAccount(form, { trial: true });
await prynt.updateEvent(requestId, { linkedId: String(user.id) });

The last line matters most, and it runs for every account you create, verified or not. PUT /v1/events/{requestId} attaches the new account to the device, so the next signup from that laptop sees it in accountsOnDevice. Skip it and every device looks new forever.

The same check runs in Python (pip install pryntid), PHP, Ruby, Go, Java and .NET, and there are ready-made recipes for Supabase, Clerk, Auth0 and Express. Mobile apps can use the iOS, Android, Flutter and React Native SDKs, which matters in markets where much of your signup traffic is on phones.

No friction for the first account

The reason this suits no-card markets is that it asks the user for nothing. A real buyer signing up for the first time sees exactly the form they saw before. Only devices that already hold an account meet a second step.

Pick that step to match your market:

Device state	Response
First account, no risk signals	Full trial, no extra step
Already holds one account	Account created, trial held until a phone OTP or WhatsApp verification
Holds several accounts, or Prynt returns challenge	No trial; offer a paid plan with a local payment method
Prynt returns block (automation, tampering, flagged device)	Refuse

The verify step is where phone checks make sense. As a gate for everyone, a phone requirement costs conversion. As a toll for the second account on a device, it’s cheap for a family sharing a laptop and expensive for someone on their tenth trial.

Things to get right in LatAm specifically

• Shared devices are normal in some segments. Family computers and shared office machines exist everywhere, so start with a limit of two accounts rather than one, and verify rather than refuse.
• VPN use isn’t automatically suspicious. Plenty of people use VPNs for privacy or streaming. Treat a VPN or proxy signal as context, not a verdict, unless it comes with automation signals.
• Write the refusal in the user’s language. “No pudimos crear una cuenta desde este dispositivo” with a support link is better than an English error and a dead end.
• Privacy rules apply. Data protection laws in Mexico and Brazil (including Brazil’s LGPD) apply to device data. Prynt honors GPC by default, supports a consent mode, and can erase data by visitorId or linkedId; the privacy page has the details.

Predictable cost matters too

Fraud tooling priced per API call in US dollars is hard to budget when your revenue is in reais or pesos and your signup volume swings with a campaign. Prynt’s plans are flat: Free at 20k identifications a month with no card, Pro at $29 for 250k with all Smart Signals, Scale at $99 for 1M. Past the quota it keeps serving about 10% more and alerts you, rather than billing a surprise overage. You only identify on the signup page, so even a busy product often fits a small plan.

Start with measurement

Run the check in flag-only mode for two weeks: let every signup through, but record accountsOnDevice.count on each new account. Then look at how many of your trials came from devices that already had one. That number tells you whether you need a hard limit, a verification step, or nothing at all.

For the broader playbook, see how to stop trial farming, device-based signup limits for choosing thresholds, and self-serve onboarding fraud for what happens after the account exists.