Stripe Radar

Risk levels and what Radar does with them

Each payment Radar evaluates comes back with a risk level: normal, elevated, high, not evaluated or unknown. Where your plan includes risk scores, there is also a number from 0 to 99. Stripe’s defaults tie the two together: a score of 65 or above indicates elevated risk, and 75 or above indicates high risk.

The defaults then act on the level. Stripe blocks high risk payments by default. On the Charge object, the outcome shows a risk_level of highest, a type of blocked, a network_status of not_sent_to_network, and the seller message “Stripe blocked this charge as too risky.” Elevated risk payments are allowed by default, and if your plan supports it, they can be sent to your review queue instead.

You can see all of this on the payment in the Dashboard, or through the API in the outcome attribute of the Charge. If Radar blocks a payment you know is legitimate, Stripe’s fix is Add to allow list on the payment. That does not retry the payment, but it stops Radar blocking future attempts from the same payment method or email address.

Rules: allow, block, review and 3D Secure

Rules are where Radar turns a score into a decision. Stripe designed them to take four actions: request 3D Secure authentication, allow the payment, block it, or send it to review. Not every action applies to every object. Charges support allow, block and review. PaymentIntents support all four. SetupIntents support 3D Secure, allow and block, but not review.

Stripe’s own examples show the range: request 3D Secure for payments from a new customer, allow every payment from your call center’s IP address, block payments made with a card issued outside your country, and review every prepaid card payment over 1,000 USD.

Radar Standard includes Stripe’s default rules, allowlists and blocklists. Writing and backtesting your own rules, setting risk preferences and using the manual review queue all require Radar Plus or Radar Pro.

Subscriptions get one special case. For recurring payments through Stripe Billing, Stripe says the AI models score only the initial payment of a subscription, while rules are still evaluated for every payment.

The four Radar plans

Stripe now sells Radar as four plans.

Radar Lite provides AI-based fraud prevention for card payments, card testing prevention and fraud alerts. Stripe’s Radar pricing page says it is included at no additional charge for businesses on standard payments pricing.

Radar Standard adds fraud protection for all supported payment methods, risk levels, default rules and lists, and fraud analytics. Stripe says businesses block 42% more fraud on Standard than on Lite, on average.

Radar Plus adds risk scores, custom rules with backtesting, risk preferences, manual reviews, Adaptive 3D Secure and Smart Refunds.

Radar Pro adds dynamic risk thresholds and protection against customer abuse: free trial abuse, bots, multiple accounts, account sharing and pay-as-you-go abuse.

For a single business, Stripe’s pricing page lists Standard starting at $10 per month, Plus at $14 and Pro at $20, with a pay-as-you-go option for each. Platforms and marketplaces have their own, higher monthly prices.

What each outcome leaves in your books

A blocked payment leaves nothing to book. It was never sent to the card network, no money moved, and there is no sale, no fee on a sale and nothing in the payout. If a customer says they were charged and you cannot find it, the payment page in Stripe will show it as blocked.

A payment in review is different, and it catches people out. Stripe says payments placed into review are typically already successfully processed, unless you capture payments later. The money is in your balance and the sale is real. Closing the review decides what happens next. Approve closes the review with no change to the payment. Refund refunds it, and Stripe notes that a completed refund cannot be undone. Refund and report fraud does the same and also reports the payment to Stripe as fraudulent. In your books, an approved review is simply the original sale, and a refunded one is a sale followed by a refund.

A payment Radar allowed that later turns out to be fraud is not Radar’s problem to fix. Stripe states that you are ultimately responsible for the payments you choose to accept, including those later disputed or found to be fraudulent. That path runs through early fraud warnings and disputes, not through Radar.

The Radar fee, and why it never sits on a sale

Radar Standard, Plus and Pro charge a fee for each screened transaction. Stripe says this applies to any authorization or charge Radar evaluates, including one-off payments, recurring transactions, invoice transactions and subscription events, and that fees are charged only when Radar screens a transaction. A payment that Radar blocks was still screened.

Subscriptions have their own rule. Radar always screens, and charges for, the first payment on a subscription and the first payment after any payment method change. Beyond that, you can set in the Dashboard how many successful renewals Radar screens before it stops, and you are not charged for the renewals it skips.

Because the fee is for a service, not for processing a particular payment, Stripe records it as its own balance transaction. Its balance transaction types reference lists stripe_fee as “Fees for Stripe software and services,” with Radar as the first example. That is why the Radar fee is never on the sales record for the payment it screened, and why it can turn up on a date with no obvious connection to any sale.

For Connect platforms, Stripe charges Radar account fees to the platform and Radar transaction fees at the rate for the account that collected the payment.