Stripe Radar Rules That Work
The prevention layer — what to actually deploy in Radar before disputes post.
Read →
Comparison · Fraud tooling
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.
Embedded in Stripe
Stripe Radar
Payment-layer fraud detection. ML scoring plus a custom rules engine, deployed natively on every Stripe charge.
LayerPayment-time
Processor lock-inStripe only
Setup timeHours
Pricing modelPer-transaction (Radar / Radar for Fraud Teams)
Best atCard-time decisioning
Processor-agnostic SaaS
Sift
ML-first risk-decisioning platform covering the full event lifecycle: sign-up, login, content, payment, and chargeback.
LayerSign-up through payment
Processor lock-inNone — agnostic
Setup timeDays to weeks (SDK + events)
Pricing modelSaaS contract (volume + seats)
Best atAccount-level abuse + cross-event signals
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.
The misconception to avoid. Don't pick between Radar and Sift on the basis of "which has better ML." Both have competent ML and competent rule engines. The decision should be made on where your fraud actually lives: at the payment moment (Radar) or upstream in account or content activity (Sift). Picking the tool that doesn't see your fraud will not help, regardless of how strong its ML is.
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
About the author
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.
Need help picking?
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.