Stripe Radar is Stripe's fraud protection. Stripe's documentation says it evaluates payments in real time using AI models to assess the risk of fraud, and that it can block a payment, send it for manual review, allow it or request 3D Secure authentication based on rules. It is built into Stripe's payment flow.
Fraud screening answers one question: is this payment likely to be unauthorized or abusive? It does not answer a second question that matters just as much to a research supplier: is this buyer someone my business should sell to? This page explains how Radar handles the first question, and why the second needs its own controls.
What Radar screens
According to Stripe, Radar screens all payment attempt types, including successful, declined, blocked and flagged payments, across the payment methods it supports. It covers transaction fraud, account risk and customer abuse. For each payment it assigns a risk outcome, and its documentation describes default rules that block payments with the highest assessed risk of fraud and require review of payments with elevated risk.
Stripe offers several Radar plans. At the time of writing, its comparison table lists custom rules, backtesting and manual reviews under the Radar Plus and Radar Pro plans, and says the Standard, Plus and Pro plans charge a fee for each screened transaction. Plans and features change, so check Stripe's current comparison before relying on a feature.
How Radar rules work
Rules let you tell Radar what to do with payments that match criteria you set. Stripe's rules documentation describes the syntax as an action, then an attribute, an operator and a value, for example an action applied if the payment amount is above a figure you choose. The actions are:
- Block: stop payments you are confident are fraudulent, or that fall outside restrictions your business has in place.
- Review: let the payment process normally but add it to a review queue for a person to check.
- Allow: let matching payments through. Stripe warns that allow rules override other rules, including its default rules, and should be used with caution.
- Request 3D Secure: ask the card issuer to authenticate the customer before the payment completes.
A few points from Stripe's guidance are worth knowing before you write rules:
- Rules apply only to future payments, not to payments already processed.
- Only the account owner, administrators and developers can create rules.
- If you are unsure about a block rule, Stripe suggests starting with a review rule, checking the results for false positives, then deciding.
- You can test a rule against recent payments before enabling it, and roll it out to a percentage of matching payments.
- Radar keeps a rule activity log showing when a rule was created, edited, enabled or disabled, and by which user.
How manual reviews work
Payments that match a review rule, or that Radar flags, go into a review queue in the Dashboard. Stripe's documentation says payments placed into review are typically already processed, unless you capture authorized payments later. From the queue, a reviewer can:
- Approve the payment, which closes the review without changing the payment.
- Refund it, without reporting it as fraud.
- Refund and report fraud, which also adds the card and email to your block lists.
If you use a capture-later flow, the review screen also shows a Capture button, and the refund option becomes Cancel. Stripe also sends webhook events when a review opens and closes, so your own systems can react.
Stripe's best practices for reviews are sensible for any team: spend human time on payments where judgment adds something, and pass order details to Stripe as metadata so the reviewer sees them in one place.
Using capture later with reviews
Stripe's fraud prevention guide explains that a card payment has two steps, authorization and capture, and that they can be done at separate times. Authorization holds the amount on the card without moving money; capture completes the payment. Stripe notes that cardholders cannot dispute uncaptured authorizations, and that an authorization not captured within the time limit is released automatically.
For a business that ships physical goods, a short hold for review often fits within normal handling time. Authorize now, capture later explains the approach, including the time limits as Stripe states them.
Fraud screening is not compliance screening
Radar looks at payment risk: the card, location signals such as IP and card country, the customer's history, and patterns across payments on Stripe. Those signals tell you whether the person paying is likely to be the legitimate cardholder. They say nothing about whether that person is a qualified business or research buyer.
That gap runs both ways:
- A genuine cardholder paying with their own card can still be a consumer who should not be buying from a research supplier. Radar has no reason to stop that payment.
- A legitimate laboratory buyer can trigger a fraud rule, for example by ordering a large amount on a new card. A fraud review should not be mistaken for an eligibility decision.
Keep the two sets of controls separate and label them clearly. Use Radar for fraud. Use your own buyer checks, signed confirmations and order reviews for eligibility, and record those decisions against the order. See how to verify business and research buyers and reviewing orders that look like consumer purchases.
Be careful with allow rules in particular. An allow rule written to reduce friction for repeat customers overrides Radar's other rules, but it does not change whether those customers fit your buyer profile.
Where Claddr fits
Claddr's rules and holds handle the eligibility side. The merchant writes rules in plain terms, and matching orders are authorized but not captured until a reviewer on the merchant's team approves them. Buyer checks, signatures, holds and payments are recorded against each order. Radar continues to do its own fraud screening on the merchant's Stripe account.
What Radar cannot do
Radar does not review your product pages, policies or marketing, and it does not decide who your business should sell to. It reduces fraud risk; it does not remove it, and not every dispute is about fraud. Stripe's prevention guidance pairs fraud tools with clear policies, responsive customer service, shipment tracking and recognizable statement descriptors.