Stripe Radar Expansion: Fraud Protection Across All Payment Methods

Stripe Radar Expansion: Fraud Protection Across All Payment Methods

In a blog post published on May 27, 2026, Samuel Bakouch, Stripe's Head of Product for Payments Intelligence, described the largest Radar expansion to date. Three things changed at once: the coverage of risk blocking extended from cards to every payment method Stripe supports; the timing moved from reacting to chargebacks to predicting before they happen; and the risk subject shifted from whether a single payment uses a stolen card to whether an account will abuse the product. Every percentage quoted here comes from Stripe's own disclosure, measured on its specific set of merchants and definitions, and does not represent the measured result of any individual business.

1. What actually changed in this release

1.1 Coverage breadth: from one payment method to all of them

Stripe states that Radar now screens for risk across every payment method Stripe supports, including bank debits, buy now pay later (BNPL), crypto payments, digital wallets, real-time payments and cash vouchers.

This addresses the most awkward gap of the past few years: card acquiring has mature models, while local wallets, bank debits and BNPL often get nothing more than basic validation, or even manual spot checks. Teams open new markets one after another while running those rails with almost no risk control at all.

The more consequential part is that signals now carry across methods. According to Stripe, once a fraud pattern is identified on one payment method, that information protects transactions on every payment method. If a fraudster using a stolen card is blocked at one business, the same IP address and device fingerprint are flagged network-wide across bank debits, wallets and BNPL.

Stripe reports that among businesses using Affirm, Cash App, Klarna and PayPal, Radar reduced suspected fraud by roughly 71% over a five-month period. Read that number carefully: it aggregates several payment methods and shows that unified cross-method risk control has leverage, but switching it on will not reproduce the same reduction in your own business.

1.2 Multiprocessor signals: moving "likely to go wrong" earlier

The new multiprocessor signals deliver two kinds of prediction. The first estimates whether a payment is likely to trigger an early fraud warning from the card network. The second estimates whether a payment is likely to turn into a fraudulent dispute.

The two are used differently. The first protects your dispute rate: refund proactively before the warning lands, so the amount never enters network reporting. The second feeds a decision: refund, gather evidence, or change the dispute strategy.

The value of these signals is that they move cost from after the fact to before it. A payment that has already become a chargeback costs you the principal, a dispute fee, dispute headroom and a permanent record; a proactive refund costs one order. Refunding too aggressively, however, damages repeat purchase and reputation, so segment by customer value: refund low-value one-off buyers without hesitation, and gather evidence first for high-value customers with a long history.

1.3 Custom fraud models: turning your own signals into a risk asset

Businesses can pass Stripe their own signals, including product catalogue data, loyalty tier, behavioural metrics or other structured metadata, and Stripe trains a custom model on top of its global network data.

A general model sees whether a transaction looks like fraud; it cannot see that this customer has been buying from you for three years. Conversely, an account that registers and places a large order ten minutes later may simply look under-informed to a general model, while your own data flags it as a clear anomaly.

Stripe reports that early adopters detected at least 15% more fraud with no increase in false positives.

The return on this capability is highly uneven. Teams with clean, structured signals get an increment; teams with messy signals simply feed noise into a model. Without a stable catalogue, membership system or behavioural instrumentation, this should not be your first priority.

1.4 New fraud types: multi-account, pay-as-you-go and bots

The most notable part of this release is not stronger stolen-card detection but a shift in the risk subject from transactions to accounts and usage.

• Multi-account abuse: a single actor creates many accounts to claim promotions repeatedly, or spreads stolen-card activity across accounts to delay detection. Stripe reports that on its network, more than one in six sign-ups at AI companies is linked to multi-account abuse. Radar evaluates each new account in real time using device fingerprint, IP and email domain signals. ElevenLabs used it to block about 2,000 users a day from abusing its free tier over a two-month period.
• Pay-as-you-go abuse: usage-based businesses accrue charges through a billing period and settle at the end, so a malicious user can consume substantial compute and never pay. Radar predicts non-payment risk while usage accumulates, letting you require a top-up or cut service before the invoice is due.
• Bot payment scoring: Radar assigns a bot score to payments made on Stripe Checkout, separating legitimate agents acting for customers from malicious bots that hoard limited inventory, abuse promotional pricing or circumvent purchase limits.

What these three have in common is that conventional risk tools cannot reach them at all: AVS, CVV and 3DS all answer whether the card belongs to the person using it, not whether the person intends to pay. If your revenue comes from subscriptions, free tiers or metered usage, this section outranks card fraud on your priority list.

1.5 Platform merchant risk signals and dispute handling

For platforms, Stripe provides a 0 to 100 fraud score per merchant and per transaction, alongside explainable AI insights, account history and notes, and account-level metrics for disputes, declines, refunds and payments.

The three new signals are fraudulent website, fraudulent merchant and merchant delinquency risk. The first reads a merchant site the way a human fraud analyst would, looking for red flags such as luxury goods at implausible prices, AI-generated copy or misspelled brand domains. The second assesses whether a new or existing account carries fraud risk. The third predicts whether a balance may stay negative for 60 days or more, so a platform can adjust settlement cadence or intervene earlier.

On the dispute side, Smart Disputes suggests AI-generated content for specific evidence fields such as tracking numbers or records of customer usage. Stripe reports that businesses adding AI-recommended evidence win three times as often as those submitting none. A new evidence library also lets you upload terms, return policies and service agreements once; Smart Disputes then selects and attaches them automatically based on reason code and network requirements.

2. Radar's three decision sources

2.1 Rules: highest certainty, quickest to rot

Rules are deterministic, explainable and auditable, which makes them right for hard constraints: blocklists, prohibited regions, per-transaction amount caps, or a limit on attempts per card in a short window.

The cost is maintenance that grows linearly with the business, and rules are static - once an attacker learns them, they route around them. The more rules pile up, the more false declines and misses appear at the same time.

2.2 Platform ML risk scores: the default baseline

Platform scores draw their value from network effects: how the same card, device or IP behaved at other businesses feeds the model. They work out of the box, their floor is high, and they are a sensible default decision layer.

The limits are equally clear: they can only answer whether a transaction looks like fraud, not whether this customer is worth the risk. The second question needs your own business judgement layered on top.

2.3 Custom models: increments above the baseline

A custom model exists to bring in a view only you have: virtual goods that cannot be resold, the repurchase cycle of long-standing members, or the correlation between a particular behavioural metric and fraud.

Quality labels and sample size are prerequisites. Fraud labels are naturally delayed and sparse, so confirm you have enough historical dispute outcomes to train and validate on; otherwise you are just dressing noise up as a model.

2.4 Division of labour and priority

A workable split is: rules for guardrails and hard constraints, platform scores for the default decision, custom models for increments, and multiprocessor signals for cross-method and proactive protection.

By stage, a business with modest volume and too few dispute samples should first exhaust rules and platform scores; move to custom models once the baseline is stable and history is sufficient. For the wider layering logic, see payment fraud prevention strategies.

3. The order in which to adopt the new capabilities

3.1 Step one: measure a baseline

Without a baseline there is no optimisation. Measure at least three numbers: the count and value of chargebacks, the direct loss from fraud, and the value of real orders you blocked (false positives).

Many teams open with "what threshold should we set", but before you know your chargeback rate, false-positive rate and average order value, any threshold is a guess.

3.2 Step two: map scores to thresholds and actions

A score only matters once it maps to an action. A common set is: allow, challenge with 3DS, queue for manual review, block, or refund proactively.

Every action carries a cost: challenges lose some real orders, manual review has a capacity ceiling, blocks generate complaints, proactive refunds give up revenue. Price those four costs first, then decide which score band triggers which action.

3.3 Step three: staged rollout and false-positive review

Run a new rule in observation mode first, recording hits without acting, and confirm the composition of the hit list looks sensible; then release it to a small share of traffic and watch how many real orders you lose.

A false positive costs a real order and a real customer, and that customer will not tell you they were wrongly blocked - they simply stop buying. That is why staging is not optional. For the metric breakdown that keeps approval rate and risk in balance, see payment success rate optimisation.

3.4 Step four: extend to multiprocessor signals and custom models

Once the baseline is stable and false positives are contained, layer on the rest: multiprocessor signals for proactive refund decisions, custom models for incremental detection, bot scores for purchase limits and promotions.

Reversing the order typically ends the same way: the model ships first, false positives spike, the team loses trust, and eventually nobody dares to tune even the basic rules.

4. The relationship with 3DS: what Radar should own after liability shift

4.1 What liability shift actually means

Once a 3DS challenge is passed, liability for fraud chargebacks shifts to the issuing bank, and your exposure on those transactions is small.

Blocking further on top of that buys "one possible loss avoided" at the price of "one real order definitely lost". For transactions that already passed a challenge, that trade rarely pays.

4.2 Authentication blind spots are the real battleground

Risk budget belongs where authentication does not reach:

• transactions that skip authentication: low-risk exemptions, low-value exemptions, and issuer flows that approve without a challenge;
• merchant-initiated transactions: subscription renewals, MOTO, instalment debits, none of which involve the cardholder in real time;
• methods outside the card network path: bank debits, BNPL, wallets and real-time payments, where the 3DS layer does not exist at all.

How those pieces fit together is covered in payment risk stack layering and 3DS2 authentication integration. The first explains the layers and their responsibilities; the second explains exemption conditions and the boundary of liability shift.

5. Chargebacks and disputes: align the metrics first

5.1 Three different ratios that must not be mixed

At least three ratios come up whenever chargebacks are discussed: chargeback count ratio, chargeback value ratio, and fraud share of payments.

The count ratio is more sensitive for high-frequency, low-ticket businesses, and a single large fraudulent order barely registers in it; the value ratio is distorted by large orders, which makes it useful for funding risk and poor for operating quality; fraud share blends fraudulent and non-fraudulent chargebacks, so it cannot judge risk-control effectiveness on its own.

5.2 Always split "challenged" from "unchallenged"

The useful version is layered: transactions that passed a 3DS challenge, transactions exempt from authentication, and merchant-initiated transactions should each have their own chargeback ratio.

Blending them causes two problems: chargebacks whose liability has already shifted get counted against your own risk control, while the category that is genuinely out of control stays hidden. For how to design the monitoring items, see building a chargeback monitoring programme; for reason codes and evidence preparation, see the chargeback reason code and evidence playbook.

6. Four cautions before rollout

• Vendor percentages come from a specific definition. Figures like 71% and 15% reflect Stripe's merchant mix and measurement window. They show the mechanism has leverage; they do not promise you the same result. Treat them as direction, not commitment.
• A custom model is only as good as the signals you feed it. Passing structured metadata is cheap, but model quality depends on how genuinely those signals correlate with fraud. An unvalidated signal is often worse than none.
• A false positive is a real order. Ask of every block: what is this order worth? The higher your average order value, the more likely the expected cost of blocking exceeds the fraud itself.
• Multiprocessor signals are prevention, not indemnity. They reduce the chance a dispute happens; they do not undo disputes already filed, and they do not change how the networks monitor you.

7. Who should adopt this first

Four tests:

• many payment methods across borders: the more fragmented the rails, the more cross-method reuse is worth;
• subscription or usage-based billing: account abuse and non-payment are the dominant losses, which is exactly what this release targets;
• platform businesses: merchant risk signals and account-level metrics plug straight into onboarding review;
• existing structured first-party data: catalogue, membership and behavioural instrumentation in place, so a custom model has inputs.

Conversely, a single-market, single-rail business with modest volume and no measured baseline gains far more from getting basic controls and metric definitions right than from chasing new features. For where this sits overall, look at the Stripe capability map, and plan it inside payment stack architecture layering.

Source: 16IDC original. Product capabilities, pricing and eligibility requirements for Stripe Blog "Expanding Stripe Radar to protect more of your business". Product capabilities and figures follow Stripe's follow its official documentation and contract terms.