Stripe Radar
Payment, connected-account, and customer-abuse risk controls
Radar combines payment fraud models, rules, review queues, and risk analytics. Its current Lite, Standard, Plus, and Pro plans also cover connected-account risk and customer abuse. Within Stripe Connect, teams can review or reject merchants, pause payouts, and manage reserves. Separate preview APIs extend risk signals to other payment processors and registration flows. This scope does not establish a full AML, sanctions, KYB, or credit-origination platform.
Our assessment
A deep fraud platform with payment-native decisions and meaningful Connect merchant controls. Evaluate each plan and integration path separately: payment scoring, account operations, and preview abuse signals have different boundaries.
Best fit and limitations
Strong fit for teams that need fraud decisions close to Stripe payments and connected-account operations. The account controls add practical merchant review, reserves, and payout restrictions. A team with other processors can evaluate the separate preview signal APIs, with its own decision and execution layer. Registration and subscription-abuse features merit a separate Pro assessment.
- Current docs list Lite, Standard, Plus, and Pro. Earlier Radar for Fraud Teams terminology and historical unit prices do not establish today's plan, regional pricing, or account entitlement.
- Custom rules, payment manual reviews, risk scores, Radar Assistant, and reserves are plan-dependent. Preview signal access is a separate condition, even when a plan comparison lists the feature.
- An ordinary review rule lets payment processing continue. Approving a review does not capture or refund a payment. ACH and SEPA Direct Debit currently lack the documented manual-payment-review flow.
- Allow rules take priority over block and review rules. For supported platform configurations, a connected-account allow rule can override a platform block rule; test the actual control hierarchy.
- Reserves and payout restrictions act on Stripe connected accounts. They do not establish control over another processor's balances. Reserve API links use a preview version, and partial-refund handling has a documented manual-release edge case.
- Multiprocessor payment signals, newer account signals, and some abuse APIs require preview or early access. The multiprocessor guide currently requires a card PaymentMethod. Treasury/outbound-money controls are separately marked Private preview.
- No reviewed source establishes native AML monitoring, sanctions/PEP/adverse-media screening, full KYB, loan credit decisions, SAR filing, or autonomous generative-agent authority. Identity is an explicit add-on.
Tools 23
Payment fraud models and risk outcomesTransaction decisions+
- Assess payment risk with network and transaction signals; return risk levels and plan-dependent scores
- Expose payment outcomes through the Charge object, including blocked, authorized, and manual-review states
- Support cards, ACH Direct Debit, and SEPA Direct Debit; other payment methods have separate availability limits
Risk controls and adaptive authenticationFraud and conversion policy+
- Configure fraud-dispute and early-warning controls around the chosen risk tolerance
- Use adaptive 3DS on supported plans; issuer and regulatory requirements still apply
- Use Pro dynamic risk thresholds to tighten card-payment controls during detected fraud pressure
Custom rules and historical testingConfigurable transaction policy+
- Write allow, block, review, or request-3DS rules using payment and customer attributes
- Test proposed rules against historical charges and inspect rule performance and history
- Apply documented action precedence: request 3DS, allow, block, then review
Radar AssistantLLM-assisted rule writing+
- Turn a natural-language instruction into a proposed transaction rule
- Refine and test the proposal before a permitted user enables it
- Review the documented use of chat inputs for assistant training before entering sensitive information
Allow lists, block lists, and custom listsReusable policy data+
- Reference customer IDs, email addresses, IPs, card or bank fingerprints, and other typed values in rules
- Manage list items through the Dashboard or API; custom lists depend on the plan
- Track item author and date; each list has a documented 50,000-item limit
Payment reviews and Smart RefundsHuman fraud operations+
- Work review queues with payment context, assignment, and action history
- Approve a review, capture an eligible authorization, refund, or report a fraudulent payment
- Use post-payment Smart Refund recommendations; review by itself does not hold the payment
Risk insights and related paymentsDecision explanation and link analysis+
- Inspect the payment, customer, geography, and network factors behind a risk assessment
- Explore payments to your business that share a customer ID, IP address, or card
- Use the insights interface within its documented six-month data window
Radar analytics centerFraud performance measurement+
- Compare fraud, dispute, block, and rule-action trends by count or payment volume
- Separate payment date from fraud-arrival date and remove repeated attempts from selected measures
- Monitor card-network program indicators; the documented analytics view has a 24-hour data delay
Transaction fraud alertsFraud-attack response+
- Receive email and Dashboard alerts when payment-risk patterns change
- Inspect affected payments, risk distributions, and potential exposure
- Review refund suggestions or adjust controls where the plan permits
Connected-account risk and agentic insightsOngoing merchant risk assessment+
- Update connected-account risk as transactions and business information change
- Inspect generated risk explanations, account metrics, related activity, and review history
- Use the findings to support a human decision; initial agentic insights can take up to 48 hours
Merchant review and payout controlsConnect merchant acceptance and restrictions+
- Raise account reviews, pause payouts or payments, and reject connected accounts
- Configure account rules that pause payouts and open a review
- Keep Treasury and broader outbound-money controls separate: those paths are marked Private preview
Connected-account reservesMerchant exposure controls+
- Create one-time holds, fixed reserve plans, or rolling reserve plans on connected-account funds
- Release funds on schedule or through a manual release; the documented maximum hold is 180 days
- Track reserved balances and hold/release transactions; the linked Reserves API uses a preview version
Fraudulent merchant signalEarly-access account intelligence+
- Assess merchant fraud using business, bank-account, transaction, dispute, and relationship signals
- Return a risk level, probability, and contributing indicators
- Receive a ready event and fetch the signal; the guide requires early-access enrollment
Merchant delinquency risk signalEarly-access loss exposure assessment+
- Identify connected accounts at risk of sustained negative balances from refunds, disputes, or payout failures
- Inspect balance, exposure, concentration, refund, payout, and related-account indicators
- Retrieve the Account Signals result and receive a readiness webhook; this is not loan underwriting
Fraudulent website evaluationEarly-access merchant website review+
- Request a website evaluation for an existing connected account or supplied business URL
- Receive a risk level and an LLM-generated explanation of suspicious or misleading content
- Handle asynchronous thin events and unknown results for inaccessible websites
Risk signals for other payment processorsPreview payment evaluation API+
- Request real-time fraud signals for payments processed outside Stripe
- Supply a tokenized card PaymentMethod, Radar Session, and customer email
- Use the returned evaluation in your own processor flow; the documented signals require preview access
Multi-account and account-sharing signalsPreview registration and login risk+
- Evaluate registration or login before collecting a payment method
- Return synchronous abuse scores using customer identity and device context
- Report the resulting user activity; live access requires Pro or its trial plus preview enrollment
Free-trial abuse controlsSubscription abuse prevention+
- Detect and block high-risk trial starts with the configured abuse control
- Use Checkout subscription integration or add the required trial metadata for other supported paths
- Enable Radar for saved payment methods and inspect historical trial results before activation
Pay-as-you-go abuse evaluationPreview post-paid service risk+
- Evaluate the risk of intentional non-payment before a usage-based invoice is due
- Provide the payment method, customer, and expected invoice amount; no Radar Session is required for this use case
- Use the returned non-payment signal in your access or billing policy; API errors do not stop the billing flow
Checkout bot controlsPro automated-traffic policy+
- Score Checkout payments for the likelihood of bot activity
- Block through the bot risk control or a custom bot-score rule
- Keep bot likelihood separate from fraud: a high score does not prove malicious behavior
Radar Sessions and client risk signalsDevice and browser data collection+
- Capture browser and device context with Stripe.js or supported mobile SDKs
- Attach session IDs to payment-method collection and payment confirmation when required
- Use the existing automatic collection in recommended Stripe payment integrations instead of duplicating it
Connected Stripe Identity step-upSeparately licensed identity verification+
- Request a government-issued document and selfie for a connected-account review
- Set a verification deadline with configured payment or payout restrictions
- Use the separate Stripe Identity add-on; this is not evidence that Radar includes full KYC or KYB
Refund-abuse signalsPreview refund-policy enforcement+
- Assess serial refund-abuse patterns using normal, elevated, or highest risk levels
- Apply custom rules or query the signal in the documented Sigma table
- Treat the result as refund-policy risk, not proof of payment fraud or customer malice
AI capabilities
Predictive models, rule assistance, and generated risk explanations
Radar uses predictive models for transaction, merchant, and abuse risk. Radar Assistant uses an LLM to draft transaction rules. Connected-account agentic insights explain risk for investigation, while the preview website signal uses LLM analysis. Model-driven blocking and scheduled reserve actions are operational automation; the reviewed sources do not establish that a generative agent can independently publish policy, reject merchants, or move funds.
What to validate
Separate model scores from final rules and user permissions. Test allow-rule precedence, false positives, unknown outcomes, and review capacity. A user must enable an Assistant proposal. Stripe documents use of Assistant chat entries for training. Confirm preview access and retain the evidence needed for model and human decisions.
Implementation
Integration checklist
- Choose the payment, connected-account, or customer-abuse flow first. Those paths use different objects, event types, permissions, and preview versions.
- Send stable customer IDs, email, address, and client context. Recommended Stripe payment integrations collect device data; other integrations can use Radar Sessions. Keep backend API keys out of client code.
- Read the Charge outcome and actual payment status separately. Handle unknown and not-assessed risk. The transaction guide says recurring Stripe Billing payments receive rules on every payment but the general fraud-model score on the initial payment.
- Verify webhook signatures against the raw body, return a prompt 2xx, deduplicate events, and re-fetch current state when events arrive out of order. Review events and preview account-signal thin events have different payload shapes.
- Use the documented idempotency contract for the API version and endpoint. The API v1 guide caches the first executed POST result, including errors, and permits key pruning after at least 24 hours. Confirm separate v2 preview behavior.
- Test review versus capture, 3DS outcomes, platform/connected-account rules, reserve releases, and failed preview evaluations. Historical tests and sandbox signals do not establish production fraud performance or a latency SLA.
Commercial scope
The current public offer uses Lite, Standard, Plus, and Pro, with plan-specific features and usage charges. Confirm local pricing, included screens, overages, connected-account or customer units, fee responsibility, and preview access in the contract. Stripe Identity, data tools, dispute services, and other Stripe products are separate unless expressly included. No regional price, legacy Fraud Teams rate, loss guarantee, or performance claim is treated as universal.
Questions for the demo
- Which current plan and preview enrollments cover our payment methods, connected accounts, customer events, and non-Stripe processors?
- Who owns rules on direct charges, and can any allow rule override the platform's intended block?
- What happens when device capture, a risk evaluation, a webhook, or a thin-event fetch fails? Which workflows continue by default?
- Which reserve and payout actions are available for our account configuration, and how do partial refunds, rejection, and release schedules behave?
- Which generated insights are retained and exportable, and which Assistant prompts can be used for training?
- How will we measure loss, approval rates, manual workload, and delayed disputes against a controlled baseline?
Engineering
- Inputs
- Charge, PaymentIntent, or eligible card SetupIntent with payment and customer context · Client browser and device metadata associated with a Radar Session · Tokenized card PaymentMethod, Radar Session, and customer email · Connected-account reserve amount or percentage with release configuration · Connected-account identifier or business URL supplied before account creation · Registration or login activity, customer or account reference, and client context; entityless email input is documented · Recognizable trial start, saved payment method, and supported subscription integration · Customer, payment method, and expected recurring invoice amount
- Outputs
- Charge outcome with risk level, available risk score, decision type, and explanation · Radar Session identifier attached to PaymentMethod or PaymentIntent radar_options · PaymentEvaluation containing fraud risk signals for an external processor flow · Review status, assignment, action history, and recommended refunds · Review object with open state, opening/closing reasons, and optional Charge or PaymentIntent reference · Connected-account risk levels, investigation evidence, and action history · ReserveHold, ReservePlan, ReserveRelease, and risk_reserved balance information · Merchant delinquency risk level and contributing financial or behavioral indicators · Website risk level and LLM-generated explanation; unknown when a website cannot be evaluated · Inline user_multi_accounting or user_account_sharing risk level and score · Trial start blocked by the configured abuse control when assessed as high risk · signals.non_payment_abuse.risk_level in a PaymentEvaluation
- Webhooks
- review.opened and review.closed report payment-review changes; the closing reason describes the disposition. v2.signals.account_signal.merchant_delinquency_ready reports a completed delinquency signal. v2.signals.account_signal.fraudulent_website_ready and v2.signals.account_evaluation.complete are thin events. Fetch the related signal or evaluation using related_object.id; data is empty. HTTPS JSON with Stripe-Signature verification over the raw body. Return a prompt 2xx, deduplicate by event identity, and handle events without assuming delivery order. Live retries run for up to three days with exponential backoff.
- Decision timing
- The guide describes real-time payment evaluation. No numerical latency SLA was established. It says recurring Stripe Billing payments run rules each time but the general fraud-model score is assigned on the initial payment. The guide describes a real-time response at a chosen point in the payment lifecycle; no measured latency or availability SLA was verified. Connected-account risk changes with new events. Initial agentic insights can take up to 48 hours after enablement. Holds release on their schedule, on qualifying refund/dispute use, or at the 180-day maximum. Released funds become available for a subsequent payout. Website evaluation is asynchronous; use a completion event and retrieve the result. Both signals return synchronously in evaluated_signals with no pending signals; the guide says no webhook or polling is required before acting.
- Deployment
- Hosted API · Web SDK · iOS SDK · Android SDK · Hosted dashboard
- Dependencies
- Server-side Stripe API key over HTTPS; restricted keys can limit permissions · Separate test and live credentials · Stripe.js or supported Stripe iOS/Android SDK · PaymentIntent creation must create a charge attempt with confirm=true when attaching the session · Enrollment in the Radar API signal preview · Client-owned integration with the third-party payment processor · A plan that includes manual payment reviews · Stripe Connect account configuration and permitted risk-operator roles · Stripe Identity add-on for document and selfie step-up · Eligible connected-account reserve access; linked API uses a preview version · Early-access enrollment and the documented Account Signals preview API · Early-access enrollment and explicit preview API version · Pro or Pro trial for live mode, plus preview access · Radar Session preferred; IP and optional user-agent/referrer fallback documented · Trial-abuse control enabled and Radar on saved payment methods · Checkout subscription mode or the documented changes for other subscription integrations · Preview access to the documented payment_evaluations API · Idempotency-Key for retryable API v1 POST operations
Verified details 54
- Deployment
Hosted API
Source Checked 2026-09-18 - Dependency
Server-side Stripe API key over HTTPS; restricted keys can limit permissions
Source Checked 2026-09-18 - Dependency
Separate test and live credentials
Source Checked 2026-09-18 - Inputs
Charge, PaymentIntent, or eligible card SetupIntent with payment and customer context
Source Checked 2026-09-18 - Outputs
Charge outcome with risk level, available risk score, decision type, and explanation
Source Checked 2026-09-18 - Decision timing
The guide describes real-time payment evaluation. No numerical latency SLA was established. It says recurring Stripe Billing payments run rules each time but the general fraud-model score is assigned on the initial payment.
Source Checked 2026-09-18 - Inputs
Client browser and device metadata associated with a Radar Session
Source Checked 2026-09-18 - Outputs
Radar Session identifier attached to PaymentMethod or PaymentIntent radar_options
Source Checked 2026-09-18 - Deployment
Web SDK
Source Checked 2026-09-18 - Deployment
iOS SDK
Source Checked 2026-09-18 - Deployment
Android SDK
Source Checked 2026-09-18 - Dependency
Stripe.js or supported Stripe iOS/Android SDK
Source Checked 2026-09-18 - Dependency
PaymentIntent creation must create a charge attempt with confirm=true when attaching the session
Source Checked 2026-09-18 - Inputs
Tokenized card PaymentMethod, Radar Session, and customer email
Source Checked 2026-09-18 - Outputs
PaymentEvaluation containing fraud risk signals for an external processor flow
Source Checked 2026-09-18 - Decision timing
The guide describes a real-time response at a chosen point in the payment lifecycle; no measured latency or availability SLA was verified.
Source Checked 2026-09-18 - Dependency
Enrollment in the Radar API signal preview
Source Checked 2026-09-18 - Dependency
Client-owned integration with the third-party payment processor
Source Checked 2026-09-18 - Outputs
Review status, assignment, action history, and recommended refunds
Source Checked 2026-09-18 - Webhooks
review.opened and review.closed report payment-review changes; the closing reason describes the disposition.
Source Checked 2026-09-18 - Deployment
Hosted dashboard
Source Checked 2026-09-18 - Dependency
A plan that includes manual payment reviews
Source Checked 2026-09-18 - Outputs
Review object with open state, opening/closing reasons, and optional Charge or PaymentIntent reference
Source Checked 2026-09-18 - Outputs
Connected-account risk levels, investigation evidence, and action history
Source Checked 2026-09-18 - Decision timing
Connected-account risk changes with new events. Initial agentic insights can take up to 48 hours after enablement.
Source Checked 2026-09-18 - Connected provider
Stripe Identity
Source Checked 2026-09-18 - Dependency
Stripe Connect account configuration and permitted risk-operator roles
Source Checked 2026-09-18 - Dependency
Stripe Identity add-on for document and selfie step-up
Source Checked 2026-09-18 - Inputs
Connected-account reserve amount or percentage with release configuration
Source Checked 2026-09-18 - Outputs
ReserveHold, ReservePlan, ReserveRelease, and risk_reserved balance information
Source Checked 2026-09-18 - Decision timing
Holds release on their schedule, on qualifying refund/dispute use, or at the 180-day maximum. Released funds become available for a subsequent payout.
Source Checked 2026-09-18 - Dependency
Eligible connected-account reserve access; linked API uses a preview version
Source Checked 2026-09-18 - Outputs
Merchant delinquency risk level and contributing financial or behavioral indicators
Source Checked 2026-09-18 - Webhooks
v2.signals.account_signal.merchant_delinquency_ready reports a completed delinquency signal.
Source Checked 2026-09-18 - Dependency
Early-access enrollment and the documented Account Signals preview API
Source Checked 2026-09-18 - Inputs
Connected-account identifier or business URL supplied before account creation
Source Checked 2026-09-18 - Outputs
Website risk level and LLM-generated explanation; unknown when a website cannot be evaluated
Source Checked 2026-09-18 - Webhooks
v2.signals.account_signal.fraudulent_website_ready and v2.signals.account_evaluation.complete are thin events. Fetch the related signal or evaluation using related_object.id; data is empty.
Source Checked 2026-09-18 - Decision timing
Website evaluation is asynchronous; use a completion event and retrieve the result.
Source Checked 2026-09-18 - Dependency
Early-access enrollment and explicit preview API version
Source Checked 2026-09-18 - Inputs
Registration or login activity, customer or account reference, and client context; entityless email input is documented
Source Checked 2026-09-18 - Outputs
Inline user_multi_accounting or user_account_sharing risk level and score
Source Checked 2026-09-18 - Decision timing
Both signals return synchronously in evaluated_signals with no pending signals; the guide says no webhook or polling is required before acting.
Source Checked 2026-09-18 - Dependency
Pro or Pro trial for live mode, plus preview access
Source Checked 2026-09-18 - Dependency
Radar Session preferred; IP and optional user-agent/referrer fallback documented
Source Checked 2026-09-18 - Inputs
Recognizable trial start, saved payment method, and supported subscription integration
Source Checked 2026-09-18 - Outputs
Trial start blocked by the configured abuse control when assessed as high risk
Source Checked 2026-09-18 - Dependency
Trial-abuse control enabled and Radar on saved payment methods
Source Checked 2026-09-18 - Dependency
Checkout subscription mode or the documented changes for other subscription integrations
Source Checked 2026-09-18 - Inputs
Customer, payment method, and expected recurring invoice amount
Source Checked 2026-09-18 - Outputs
signals.non_payment_abuse.risk_level in a PaymentEvaluation
Source Checked 2026-09-18 - Dependency
Preview access to the documented payment_evaluations API
Source Checked 2026-09-18 - Webhooks
HTTPS JSON with Stripe-Signature verification over the raw body. Return a prompt 2xx, deduplicate by event identity, and handle events without assuming delivery order. Live retries run for up to three days with exponential backoff.
Source Checked 2026-09-18 - Dependency
Idempotency-Key for retryable API v1 POST operations
Source Checked 2026-09-18
Vendor example
Published vendor example. Confirm the current version and required credentials.
{
"id": "prv_1NVyFt2eZvKYlo2CjubqF1xm",
"object": "review",
"billing_zip": null,
"charge": null,
"closed_reason": null,
"created": 1689864901,
"ip_address": null,
"ip_address_location": null,
"livemode": false,
"open": true,
"opened_reason": "rule",
"payment_intent": "pi_3NVy8c2eZvKYlo2C055h7pkd",
"reason": "rule",
"session": null
}Integration limits
- Published vendor payload example, linked to its source. It is not a complete integration or a tested production request.
- Empty country, deployment, or provider lists mean not verified in this review. A documented country refers to the specific product noted in its source, not universal platform coverage.
- Use the endpoint-specific authentication and API version. No self-hosted deployment or complete country-availability list was verified.
- Handle unknown and not_assessed outcomes separately from payment status. A successful risk assessment does not guarantee issuer approval or absence of later fraud.
- Create the session late in the flow. Recommended Stripe payment integrations already provide the relevant client data; avoid duplicate session integration. Off-session data can be attached when the payment method is saved.
- The current guide limits PaymentMethod support to cards. Evaluation returns risk intelligence; the merchant server separately transacts with its processor.
- Approving a review closes it without changing the payment. Capture and refund are separate actions. ACH and SEPA Direct Debit currently lack this manual review flow.
- The example is the exact published test-mode response object. It is not a request, webhook envelope, executed API response, or promise that every optional field is populated.
- Account rules can pause payouts and create reviews. Treasury and broader outbound-money paths are Private preview. Connected Identity is an add-on, not included Radar KYC.
- A smaller partial refund or dispute can leave the hold in place and require manual release. Changing a rolling plan affects future holds; disabling a plan releases existing holds and cannot be used as a temporary pause.
- This signal concerns unrecoverable negative merchant balances. It is not evidence of loan affordability, credit bureau coverage, or credit-origination decisions.
- Sandbox URLs return deterministic fixtures rather than a live website crawl. This does not verify legal-entity registry records or beneficial owners.
- Report registration or login outcomes. Reuse customer identifiers across the flow. An IP-only fallback has less information than a full session.
- This is trial-abuse prevention, not a general credit approval or debt collection service. Confirm plan entitlement and the exact integration path.
- Radar Session is optional for this use case. API errors do not stop the subscription flow. Fraudulent-payment score fields can be -1 because they do not apply; use the non-payment signal for this decision.
- Thin and snapshot events have different contracts. Re-fetch current state where needed. The webhook retry window is not a decision-latency SLA.
- The first executed status and body are replayed, including 500 responses. Keys can be pruned after at least 24 hours; changed parameters produce an error. Validation failures and concurrent-execution conflicts are not saved. Confirm v2 preview semantics separately.
Sources 28
Source review dates are shown above. Product claims come from public sources. Fit, limits, and evaluation questions are our analysis. This is not a hands-on performance test. Methodology · Changelog