Fraud detection API options for SaaS: Radar, Sift, Fingerprint, and the self-serve gap

If you are shopping for a fraud detection API this week, something already happened. A card-testing run hit your checkout, or a few hundred trial accounts appeared from the same device, or someone stuffed credentials into your login form overnight. The tools you will find have very different shapes, and most of the confusion comes from comparing tools that cover different layers as if they were substitutes.

This post lays out the landscape by layer and by buying model. Every price and every capability below comes from the vendor's own public page, linked in the sentence. Where a vendor does not publish pricing, the table says so.

I build one of the tools on this list. It appears once, in the section on the self-serve gap, with its limits stated.

The four layers

Abuse against a software business happens at four places, and the tooling market has organized itself around them.

The bot layer asks whether a browser is driven by a human. CAPTCHAs, Turnstile, hCaptcha and Arkose live here. They are cheap, they run before your code does, and they say nothing about whether the human on the other side is the same human who abused you last month.

The device layer answers "have I seen this browser before?" A fingerprinting API returns a stable identifier across incognito windows and cleared cookies. It is an input. You still have to build the counters and the rules.

The payment layer scores a charge. Stripe Radar is the default because it is already in your account. It sees the card, the issuer response, the network's history of that card fingerprint, and the amount. It does not see your signup form, your trial, or your login.

The identity layer links accounts to each other. This is where "the same person keeps coming back with a new email" gets answered, because it joins email, device, card fingerprint, phone and wallet into a cluster and remembers what that cluster did. Sift and Castle sell this to enterprises. It is the layer indie SaaS has historically gone without.

Most attacks cross layers. A card tester is a bot problem at the checkout form, a payment problem at authorization, and an identity problem when they come back tomorrow with a fresh Stripe Customer. That is why one tool rarely closes the hole.

Stripe Radar

Radar is the tool you already have. Stripe's pricing page says Radar Lite, "AI-based fraud prevention for card payments and card testing, plus fraud alerts", is included at no additional charge for businesses on standard payments pricing, and it lists Radar Standard, Plus and Pro starting at $10, $14 and $20 per month (stripe.com/radar/pricing). Per-transaction rates are behind a pricing toggle, so check the page for your own volume.

The plan comparison in the docs is where the real decision lives. Custom rules, backtesting, manual reviews and risk preferences start at Radar Plus, while free-trial abuse, bot abuse, multi-account and account-sharing signals are Pro-only, according to Stripe's plan table. The same page notes Radar does not screen SetupIntent objects for non-card payment methods.

What Radar is good at: scoring a card charge using the whole Stripe network's history of that card. If a card number was tested across a hundred other Stripe accounts last night, Radar knows and you do not.

What it is not: a signup or login tool. There is no event you can send Radar when a user registers, and the multi-account signal in Pro fires on payment objects, not on your users table. If your abuse is trial farming, Radar sees it only when the abuser finally pays, which for trial abuse is never.

Radar's defaults are also tuned for the network, not for you. In a June 2023 thread about a card-testing attack on Stripe, ruffrey wrote: "Stripe has the tools to deal with it, but you must configure it." The rules that stop card testing at ordinary amounts, velocity per card and per IP, are custom rules, and custom rules require Radar Plus.

In a May 2026 thread titled "Stripe is friendly to 'friendly fraud'", ripberge, who described selling tickets to tourists, wrote: "Stripe Radar was not a good product. It would score large numbers of very suspect transactions at a risk level of 1 or 2 (out of 100)." jhmeltzer, who said they lead Radar engineering at Stripe, replied: "We know this kind of fraud abuse is maddening." Radar is a payment-scoring model trained across every Stripe merchant, and for a business whose fraud looks unusual, no tier upgrade changes what the model sees.

The mechanics of card testing and the Radar rules that matter are in what is card testing.

Fingerprint and FingerprintJS

Fingerprint sells device identification as an API. The free plan covers 1,000 API calls a month, Pro Plus is $99 per month for 20,000 calls with $4 per additional 1,000, and Enterprise is custom with a 99.9% SLA, per the Fingerprint pricing page. Pro Plus adds Smart Signals, where VPN, incognito and bot detection live.

The open-source library has a licensing history worth knowing. Version 4 moved to the Business Source License, and version 5 went back to MIT, according to Fingerprint's own announcement. The README says the open-source library's accuracy "is significantly lower than in the commercial version" because it runs entirely in the browser (github.com/fingerprintjs/fingerprintjs). That is the real FingerprintJS alternative question: the OSS library gives you a hash of browser attributes that two identical laptops will share, and the paid API gives you server-side reconciliation that makes the identifier stable.

Either way, what you get is an identifier. To turn it into a verdict you need to store it against your users, count distinct accounts and cards per device, decay those counts, and pick thresholds. That is the work the identity-layer tools sell. Fingerprint is the right buy when you already have a risk engine and it is missing a device key.

Sift, Castle, and the enterprise account-defense tier

Sift's site lists Payment Protection, Account Defense, a Score API and Expert Services, and every call to action is "Demo Sift" (sift.com). There is no public pricing page and no self-serve signup. That is the business model, not a flaw. Sift's identity graph and review console are the reference design for the identity layer, and the price reflects a fraud team that will use them.

Castle is the closer comparison for a small team, because it publishes numbers. The Castle pricing page lists a Free plan with $5 of monthly credit (1,000 Risk API calls or 5,000 IP lookups), a Pro plan at $200 per month with $200 of credit (40,000 Risk API calls or 200,000 IP lookups), and Enterprise starting at $4,000 per month. The Risk API is a genuine identity-layer product: device, IP, email and behavioral signals with a policy engine and a dashboard. For a SaaS with a fraud budget of a few hundred dollars a month, the $200 tier is reachable. The free tier's 1,000 calls is enough to evaluate and not enough to run on.

The products in this tier are mature, the graphs are deep, and the pricing is designed for companies where a fraud analyst is a job title.

Arkose Labs, hCaptcha, Turnstile: the challenge layer

Challenge widgets answer one question, whether a browser is automated, and they answer it before your server runs.

Cloudflare Turnstile is free, with up to 20 widgets per account and 10 hostnames per widget, and an Enterprise tier that lifts those caps, per the Turnstile plans page. hCaptcha's Basic plan is free, Pro is $99 per month billed annually (or $139 monthly) for 100,000 evaluations with $0.99 per additional 1,000, and Enterprise is custom, per the hCaptcha pricing page. Arkose Labs publishes no pricing; its site routes everything through "Schedule a Demo" (arkoselabs.com).

Put Turnstile on your signup form today. It costs nothing and it removes the dumbest traffic.

Then understand what it does not do. A challenge widget has no memory of your users. It cannot tell you that this human already burned three trials, or that this card fingerprint appeared on five accounts yesterday. Attackers who care route through residential proxies and farm out challenges; a solved challenge is a line item in their spreadsheet. The challenge layer lowers volume. It does not decide.

WorkOS Radar and auth-layer protection

WorkOS Radar is a newer entry aimed at the auth layer. WorkOS lists the first 1,000 checks free and $100 per month per 50,000 additional checks (workos.com/radar). The Radar docs describe bot detection, brute-force detection, impossible travel, unrecognized devices, suspicious-domain blocking and "repeat sign up attempts from the same email", built on device fingerprinting.

If you are on AuthKit, this is close to free protection for login and signup, and you should turn it on. Two limits. It lives inside the auth flow, so it never sees a checkout, a trial conversion or a card. And the repeat-signup signal, as documented, keys on email, which is the identity key attackers rotate first.

Open-source pieces

Two free components carry more weight than their size suggests.

The disposable-email-domains list is CC0, holds a few thousand domains, and is used by PyPI to block registrations. It will not catch a throwaway Gmail, but it catches the mailinator tier in one string comparison, and it is the first thing to wire into a signup handler.

FingerprintJS v5, now MIT again, gives you a client-side device hash. Pair it with a counter in your own database and you have a crude but real device velocity check.

Between the two you can build a signup filter in an afternoon. What you cannot build in an afternoon is the memory: the table that says this device, this card fingerprint and this phone all belong to the account you banned in March.

The self-serve gap

Line the tools up by buying model and a hole appears.

Turnstile, hCaptcha, Fingerprint and WorkOS Radar are self-serve and each cover one layer. Radar is included with Stripe and covers payments, with the abuse signals that resemble an identity layer gated to Pro. Sift and Arkose are sales-led and cover everything, at a price and a process built for fraud teams. Castle publishes a $200 tier that gets close.

What a ten-person SaaS needs is the identity layer, meaning multi-signal linking with memory and a review queue, across every moment an abuser touches the product, at a price that fits under a Stripe fee line. Historically that combination did not exist. You either stitched together three self-serve inputs and wrote the decision logic yourself, or you waited until you were big enough to take the sales call.

Portreeve is the tool I built to fill that gap. One API call at signup, trial_start, trial_convert, checkout_attempt or login returns allow, review or block plus reason codes in under 100 ms. Accounts are linked across hashed email, device fingerprint, card fingerprint, phone and payer wallet, so confirmed abuse on one account marks the whole cluster. review never blocks the user: the event goes to a queue in the dashboard and a later deny reaches your server by signed webhook. The SDK fails open by default. Pricing is Free for 1,000 screened events a month with no card, then $19, $79 and $249 per month for 10,000, 50,000 and 250,000 (pricing). It is in open beta with no uptime SLA yet, and there are no published catch rates or benchmarks against anything above.

The design choice worth understanding regardless of what you buy is the review verdict. Every tool on this page that returns a score leaves you to pick a threshold, and every founder picks it wrong at first because false positives are invisible until a paying customer emails you. A three-state verdict where the middle state costs the end user nothing lets the engine flag aggressively and reserve block for high-confidence shapes. The verdict handling docs walk through the review path, and the reason codes reference lists what the engine will tell you about why.

One more mechanism note. Blocking card testing at ordinary amounts requires a device-keyed counter, which means a browser fingerprint has to be collected at the checkout form. Without it, the shapes that indicate testing top out at review. The device fingerprinting docs cover the snippet and the token flow. The same constraint applies to any tool: no device key, no blockable card-testing rule.

Choosing fraud detection for SaaS

The decision is by attack, not by vendor. Here is the landscape as verified above.

If you only have card testing, stay inside Stripe first. Radar Lite already blocks some of it, and the Plus tier gets you the velocity rules. Add a device fingerprint to the checkout form before anything else, because without it no tool can block the low-amount ladder at high confidence.

If you have trial abuse, Radar will not see it and a CAPTCHA will not remember it. You need something with a signup event and memory. WorkOS Radar if you are on AuthKit, Castle or Portreeve if you need the graph to also cover checkout and trial conversion.

If you have account takeover, the signal is "unrecognized device against this account's history", which is a login-event feature. WorkOS Radar covers it inside AuthKit. Sift's Account Defense is the enterprise version.

Do not put "require a card up front" on the list as a fraud control. It stops the laziest trial abuse and hands card testers a SetupIntent endpoint that validates a card without moving money, which is exactly what they came for.

Whatever you pick, wire the feedback loop. A tool without your chargebacks and your confirmed-abuse labels is scoring with half the information.

If you want to see what the identity layer looks like at self-serve pricing, create a free Portreeve account. The free tier covers 1,000 screened events a month and does not ask for a card.