Stripe Radar vs Sift
Operator's comparison of the two most common fraud-prevention layers used by subscription apps. Rule engine vs ML-first, deployment model, pricing structure, integration depth — and when each is the right call.
Stripe Radar
Payment-layer fraud detection. ML scoring plus a custom rules engine, deployed natively on every Stripe charge.
Sift
ML-first risk-decisioning platform covering the full event lifecycle: sign-up, login, content, payment, and chargeback.
The structural difference
Stripe Radar and Sift solve overlapping but materially different problems. Radar is a payment-time decisioning tool: at the moment of charge, it scores the transaction and returns block / review / allow / 3DS. It has visibility into Stripe's payment-network signals (card BIN history, prior Stripe fraud reports, payment-time velocity) but limited visibility into pre-payment events on your platform. Sift is a platform-wide event-scoring tool: it accepts events for sign-up, login, content posting, account changes, payment attempt, chargeback, etc., and runs a unified ML model across them. Sift can flag a suspicious sign-up before the user ever attempts a payment.
This shapes what each tool catches well. Radar catches stolen-card fraud at the moment of authorization. Sift catches the synthetic-account ring that signed up 50 accounts in 12 hours and is now trying to test cards — Sift can score the sign-up cohort before any Stripe charge happens. Radar can stop the eventual charges; Sift can prevent the accounts from existing in the first place.
Full side-by-side
| Attribute | Stripe Radar | Sift |
|---|---|---|
| Vendor | Stripe | Sift (independent vendor) |
| Core model | ML scoring + custom rule engine | ML-first decisioning with optional workflow rules |
| Event coverage | Payment-time only (charge, refund, dispute) | Full lifecycle: sign-up, login, content, payment, chargeback |
| Processor support | Stripe-processed transactions only | Processor-agnostic; integrates with any backend |
| Deployment | Native in Stripe Dashboard — no integration needed for baseline; rule editor for custom rules | SDK-based event instrumentation; backend API for scoring; webhook for decisions |
| Setup time | Hours to first custom rule | Days to weeks depending on event coverage scope |
| Engineering cost (initial) | Minimal — rules in dashboard | Material — event instrumentation across the product |
| Engineering cost (ongoing) | Low — rule maintenance only | Moderate — event schema maintenance, model feedback loops |
| Rule transparency | High — operator writes rules in dashboard syntax | Mixed — ML scores are opaque; workflow rules are explicit |
| ML model transparency | Risk score (0-100) with directional signals | Risk score plus feature contributions in the dashboard |
| 3DS gating support | Native — rules can force 3DS | Yes via processor integration; not native to Sift |
| Dispute / chargeback management | Built-in Stripe representment + Stripe Chargeback Protection (Radar for Fraud Teams) | Sift Dispute Management is a separate product |
| Pricing | Per-transaction; Radar included in standard Stripe; Radar for Fraud Teams adds per-charge fee | SaaS contract; volume + seat based; negotiated per customer |
| Best fit operator profile | Stripe-processed subscription apps with payment-time fraud problems | Multi-processor businesses or apps with significant pre-payment account abuse |
When Stripe Radar is the right call
- Your fraud problem is concentrated at payment time (card testing, stolen cards, BIN-IP mismatches).
- You're already on Stripe and not planning to add other processors.
- You want operator control via custom rules rather than a black-box ML model.
- You're a smaller subscription app where Radar's included tier is sufficient and Sift's contract minimum is unjustifiable.
- Your engineering team is small and can't fully instrument event tracking across the product.
When Sift is the right call
- Your fraud problem is concentrated upstream of payment — sign-up abuse, multi-account rings, account takeover.
- You process payments across multiple processors and want unified risk scoring.
- You operate on a non-Stripe processor where Radar is unavailable.
- You have the engineering resources to instrument events across the product lifecycle and maintain the feedback loop.
- Your business model includes user-generated content or social features where content-abuse signals matter.
When to use both
Many subscription apps that reach Series B or larger volume end up running both. The two layers are complementary: Sift handles sign-up scoring and account-level risk decisions; Stripe Radar handles payment-time decisions on Stripe-processed charges. The cost overhead is real but the false-positive rate is materially lower than either layer alone, and the combined coverage catches the multi-account synthetic-identity ring patterns that pure Radar misses (because Radar only sees the moment of charge, not the months of sign-up activity leading up to it).
The pattern I've seen work most consistently: Sift scores sign-ups and gates account creation. Radar scores the eventual payment, using the Sift account-level risk score as a Radar input (Stripe accepts custom metadata in Radar rules). The two layers reinforce each other.
If you're approaching VAMP or ECM thresholds
Neither tool alone solves a card-network monitoring problem. Radar prevents pre-authorization fraud but cannot prevent disputes after the charge settles. Sift extends coverage upstream but also stops at authorization. For chargebacks already in flight — friendly-fraud disputes on legitimate authorizations — neither tool helps. That layer is dispute interception via Ethoca and Verifi, plus structural fixes to billing descriptors, renewal notifications, and self-serve refund flows.
The full operator playbook for ECM and VAMP exit, including which fraud tool to deploy at which stage, is in the 90-day rescue program.
Read next
- → Stripe Radar Rules That Actually Reduce Chargebacks — full guide
- → 14 copyable Radar rule recipes organized by failure mode
- → Ethoca vs Verifi — dispute interception comparison
- → Every card network monitoring program subscription apps need to know
- → Free VAMP & ECM risk calculator
Georges Rayess drove the chargeback rate at a privacy-focused subscription mobile app from 13% to below 1% using a tuned Stripe Radar configuration plus Ethoca dispute interception. Connect on LinkedIn.
Get a stack-level diagnosis
First call covers where your fraud actually lives — payment, sign-up, or account — and which tool layer matches your problem.