SoftTech AI Registry
Stripe · Radar

AI risk-based payment blocking

Stripe Radar uses AI/ML-derived fraud-risk assessments to evaluate payment attempts and can automatically block payments that cross Stripe's applicable fraud-risk enforcement boundary, preventing the attempted transaction from completing through Stripe's processing path. Merchant-written custom rules are outside this record.

Recorded characteristics

Function
Radar evaluates payment fraud risk using Stripe AI/models and automatically blocks qualifying high-risk payment attempts under Stripe-controlled risk enforcement without requiring a human to approve the individual block at runtime. For the documented high-risk charge path, Stripe records the transaction as blocked and not sent to the payment network. Stripe states: "Stripe Radar includes adaptive AI models that use a risk score to evaluate the risk level for each payment in real time." "Stripe reports payments as high risk when we believe they're likely to be fraudulent. Payments of this risk level are blocked by default." The documented outcome is network_status "not_sent_to_network", reason "highest_risk_level", type "blocked", seller_message "Stripe blocked this charge as too risky." Current architecture: Stripe states "Radar is deprecating the high risk block rule that uses risk score to block payments. To change your block preference, you must use risk settings, which use separate models to block payments." "Risk controls use AI to protect your account." "Each risk control uses individualized machine learning"; "Risk settings automatically manage the blocking thresholds for risk controls." The Fraudulent card payments control "blocks payments that Stripe Radar determines are likely fraudulent ... it acts at the time of payment"; "Radar determines the blocking threshold based on your risk setting." Dynamic risk thresholds "automatically blocks additional elevated and high-risk payments when your account is under fraud pressure", using machine learning. The legacy rule "Block if :risk_level: = 'highest'" is retained as historical/transition evidence only; the capability is not bound to it. The direct controlled object is an attempted Stripe payment (Radar runs on Charges, PaymentIntents and SetupIntents; the documented Block action blocks "the creation of the object").
Data access
Stripe states the model "uses hundreds of risk factors about each payment and data across our network of businesses to predict whether a payment is likely to be fraudulent", learns from new purchase patterns and transaction features, and incorporates merchant fraud feedback. Radar screens cards (and card-backed wallets), ACH Direct Debit, SEPA Direct Debit and, in private preview, other payment methods.
Actions
Can take actions
External actions
Yes
Human confirmation
Not required
Permission basis
Not established
Administrative control
Human confirmation (not_required): the qualifying Stripe-controlled block of a high-risk payment executes without a person approving that particular block at runtime. Prior configuration (risk settings, plan choice) is configuration, not runtime confirmation. Manual review is a separate path: elevated-risk payments are allowed by default and, where the plan supports it, can go to a review queue ("Review if :risk_level: = 'elevated'"); account-level risk rules also route to review. These review paths are not the blocking path. Merchant controls: choose or modify a risk setting (Maximize protection, Balance risk and revenue, Maximize revenue), which "automatically adjusts the blocking threshold"; set a custom threshold for the Fraudulent dispute control (Manual mode); add a blocked payment to the allow list; opt out of Radar fraud risk assessment. Stripe states "Risk controls and risk settings won't override the custom rules you created." Auditability: Stripe exposes risk level, risk score (only with certain Radar plans), outcome type, blocking reason, network status, seller message and a risk insights section explaining why a level and score were assigned. This is not complete model explainability.
Default state
Enabled
Availability
Default state (enabled), with variation recorded: Stripe states high-risk payments "are blocked by default" (S01); the legacy rule "Block if :risk_level: = 'highest'" is described as "enabled by default" but "Deprecated" (S03); "Stripe automatically enables the fraudulent non-card payments control by default for all non-card, local payment methods" (S02). Variation: the Fraudulent card payments control is "included with Radar Standard and above"; when a merchant first enables a risk setting, Stripe disables the high-risk block rule and it cannot be re-enabled, with blocking then governed by the selected risk setting's thresholds; Stripe does not publicly name which risk setting applies to a new account; risk evaluation covers card, ACH and SEPA Direct Debit, with other non-card methods set to not_assessed; businesses can opt out. Radar Lite is described as "AI-based fraud prevention for payments"; whether every plan blocks identically by default is not established.
Licensing
Radar Lite, Standard, Plus and Pro plans; Standard, Plus and Pro charge a fee per screened transaction. Risk score visibility, review queues and custom rules depend on plan.
External model or provider
Stripe's own adaptive AI models (risk score) and "more specialized models" used by risk settings and the fraudulent-dispute and early-fraud-warning controls. No external model provider is documented. The fraudulent non-card payments control determines risk "based on attributes that Stripe has identified as high fraud risk on other payments"; whether that control is model-based is not explicitly stated.
Limitations and uncertainty
Negative control — merchant-written rules: Radar custom rules (e.g. a merchant rule on :risk_score: above a threshold, or rules on country, amount, card origin, email, IP, payment method or other fixed transaction characteristics) can block payments automatically but are not evidence for this record. Only Stripe's own model-derived risk evaluation with Stripe-controlled enforcement (default high-risk blocking, risk controls whose thresholds Radar manages) is in scope. Not conflated with: issuer decline (Stripe passes on issuer information separately), refund, reversal, chargeback, account freeze, card cancellation, bank restriction, settled-payment reversal, criminal fraud determination or merchant account termination. Radar does not command an issuer to decline, freeze a bank account, change the customer's bank balance or block the customer at other processors. Outside action (yes): Radar prevents an outside customer's attempted commercial payment from completing through Stripe's processing path. Reversibility: Original blocked payment attempt remains unsuccessful; merchant intervention such as allow-listing may permit a later attempt, but does not reverse or resume the original transaction ("Adding a payment to the allow list doesn't retry the payment"). Automatic model-driven restoration/resumption: Not Publicly Established. Failure behaviour: Stripe documents that when an error causes risk evaluation to fail, the payment is reported as unknown risk; the documented example shows it approved by network. This is a documented example, not a universal fail-open guarantee. Blast radius: the direct action target is an individual payment attempt. Allow lists and block lists act on payment methods and email addresses but are separate features. Maximum aggregate automatic blocking scope: Not Publicly Established. Not Publicly Established: exact production model architecture; current model version(s); full training dataset; complete feature weighting; exact risk-score formula; production calibration methodology; universal model confidence thresholds; universal Stripe-controlled blocking threshold (S01 states default score bands of 65 elevated and 75 high); all regional/account/payment-method variations; exact internal execution identity/principal; universal fail-open/fail-closed semantics; model-service outage behaviour; evaluation retry semantics; duplicate-evaluation handling; exactly-once enforcement; Radar-specific idempotency; model-version attribution per payment; complete model provenance; maximum aggregate automatic blocking scope; automatic restoration of blocked false positives; universal merchant override semantics; identical enforcement sequencing across every payment method. Permission basis is not_established: enforcement is platform-side and no Registry execution identity is documented.

Evidence