Fraud Prevention for a Two-Person SaaS: What to Set Up First

When you are two people running a SaaS product, “fraud prevention” sounds like something for banks. Then one morning your free tier has 400 new signups from the same three email domains, your LLM bill has doubled, and a customer emails to ask why their card was charged by someone else’s account. Fraud did not wait for you to hire for it.

The good news is that small teams face a small set of problems, and most of them have cheap, boring fixes. This is the order to set them up in, what to skip for now, and how to keep it to an hour a week.

Priority 1: signup

For a product-led SaaS, almost all early abuse starts at signup. Three things happen there:

• Free-tier and trial farming. One person creates many accounts to keep using the free plan or to stack trial credits. On AI products this is direct cost; see free-credit abuse on AI products.
• Bot signups. Scripts create accounts for spam, SEO links, referral rewards or to test stolen cards later.
• Fake accounts staged for later abuse. Accounts that sit quietly until they are used for spam or phishing from your domain.

Email checks alone fail because emails are free. IP limits fail because proxies are cheap and real offices share IPs. What works is keying on the device:

1. Identify on the signup page and send the requestId with the form.
2. On the server, fetch the event and check decision and accountsOnDevice.count.
3. After creating the user, link it with PUT /v1/events/{requestId}.

That is the whole integration. If you use Clerk, Supabase or Auth0, there are ready-made recipes for exactly this flow, and an Express middleware for custom stacks. The default policy blocks at two other accounts on the device, blocks when Prynt says block, and flags (does not block) when the requestId is missing, so privacy-conscious users and script blockers can still sign up.

Pick a soft limit. For most small SaaS products, “second account on a device works, but does not get a fresh trial” is better than a hard block. It costs abusers the thing they wanted and costs honest users nothing. The protecting free plans guide goes deeper on the options.

Priority 2: login

Once you have paying customers, their accounts are worth attacking. Small SaaS products get hit by credential stuffing because their users reuse passwords from breached sites.

What to set up, in order:

1. Rate limits on the login endpoint, per account and per device, not only per IP.
2. Offer MFA, and require it for admins and anyone with billing access.
3. Identify on login with the user id as linkedId. This links accounts to their devices and enables account-level signals.
4. Step up on risk: when the login decision is challenge, or the device is new for that account and the network looks off (VPN, datacenter, a country you do not serve), ask for an email code instead of letting the session through.
5. Notify on new devices, so the real owner sees a takeover in progress.

The SaaS account security guide covers each step in more detail.

Priority 3: payment

If you take cards, you will eventually meet card testing: bots running stolen card numbers through your checkout with small charges to see which ones work. Your payment processor’s own fraud tools catch a lot of this, so turn them on first. Then:

• Require an account before checkout, so the signup protections apply.
• Identify at checkout and refuse to create payment attempts for sessions Prynt marks block or that show strong automation signals.
• Cap payment attempts per device per hour. A real customer does not try nine cards in ten minutes.

Card testing is mostly a bot problem, so the same bot detection signals you use at signup apply here.

What can wait

Small teams waste time building things they do not need yet. You can safely postpone:

• Machine-learning models. You do not have the labeled data, and rules on clear signals will outperform them at your volume.
• A manual review team. Use a simple weekly review instead (below).
• Elaborate rule sets. Five rules you understand beat fifty you do not.
• Chargeback management tooling, until chargebacks are a measurable line item.
• Building your own fingerprinting. It looks easy and becomes a maintenance project. See build vs buy.

What the free plan covers

The Prynt Free plan is $0 with no card: 20,000 identifications a month, visitor ID with confidence, bot detection, and IP geolocation with ASN. If you identify only at signup, login and checkout, that covers a lot of early-stage traffic, and accountsOnDevice works for signup limits. On Free, act on the account count and the bot signal directly; the risk decision with reason codes is driven by the Smart Signals set.

The Pro plan at $29 a month adds all Smart Signals: VPN, Tor, datacenter and residential proxy detection, behavioral signals, AI-agent detection, JA4 TLS fingerprinting and the reputation network. Load the agent with extendedResult: true so those signals and the decision are computed for each identification. Upgrade when you need to reason about networks and automation, not before. If you exceed the quota, service continues for roughly 10% more with alerts at 80% and 100%, so a traffic spike does not take your signup down. Details are on the pricing page.

How to avoid building a fraud team

The practices that keep this to an hour a week:

• One policy module. Keep allow / flag / verify / block logic in one file, not scattered across handlers.
• Fail open on errors. If the fraud API is down, let signups through and flag them. An outage should not become a signup outage.
• Flag before you block. Run every new check in flag-only mode for a week or two and read what it catches.
• A weekly 30-minute review. Look at the devices with the most accounts, the flagged signups, and any chargebacks. Act on clusters, not individuals.
• Label outcomes. When you confirm abuse, report it with POST /v1/outcomes so the same devices are recognized next time.
• Neutral user messages. “We couldn’t create an account from this device. Contact support if this is a mistake.” Never explain what you detected.

A one-week rollout

• Day 1: add identify to the signup page, verify on the server, link the account. Flag only.
• Day 2–3: add login identify with linkedId and new-device email notifications.
• Day 4: turn on your payment processor’s fraud rules; add a per-device cap on payment attempts.
• Day 5–7: read the flagged signups. Switch the device limit from flag to “no fresh trial.”

That is a meaningful fraud program for a company of two, and every piece of it scales when you grow. Start with the signup step on the free plan, and add the rest as your traffic grows.