Ecommerce Fraud Prevention: Stripe Radar and Flow Setup

Ecommerce fraud prevention on Shopify is not one setting you switch on once — it’s five separate pieces of configuration, sitting in at least three different systems, that only work when they agree with each other and stay tuned as order volume grows. A store doing $3M–$30M in revenue on Shopify Plus or a paid subscription platform usually has more of this switched on already than the team running it realises: Shopify’s own fraud analysis runs on every order by default, Stripe Radar screens every card charge whether or not anyone has opened its settings, and neither one is configured for the catalogue or the volume actually being sold. What follows is the setup in order — what to turn on, the real setting values, the one step almost every team gets wrong, and how to check afterward that any of it is doing something rather than generating a number nobody reads.

What Do You Need Before You Start Setting Up Ecommerce Fraud Prevention?

Ecommerce fraud prevention setup needs three things in place before a single rule gets written: admin access to whichever processor is actually charging the card, at least three months of order history to test a new rule against before trusting it, and a decision about which error costs more — a fraudulent order that ships, or a good customer refused at checkout.

• Processor access. Shopify Payments and a directly connected Stripe account expose different settings screens for the same underlying Radar engine, so confirm which one is actually processing cards before following any setting value below.
• A baseline. Pull the store’s current chargeback rate and fraud-related refund rate from the payments dashboard before changing anything. Every setting in this guide gets judged against a change in those two numbers, not against how confident the new rule feels in its first week.
• A stated risk tolerance. Decide, in writing, whether the team would rather ship an occasional fraudulent order or lose an occasional legitimate customer to a false decline — because every rule below moves that trade-off in one direction, and nobody should be discovering which direction after the fact.

Step 1: Turn On Shopify’s Fraud Control App and Read the Right Number

Ecommerce fraud prevention on Shopify starts with installing the free Fraud Control app and reading its chargeback-health status correctly, not just glancing at the order-level risk flag. Shopify’s own documentation states the app is free to install from the Shopify App Store on any plan where Shopify Payments is the processor, and its dashboard reports three chargeback-health bands: under 0.4% of orders is good standing, 0.4%–0.6% is at risk, and over 0.6% is the highest-risk band.

Those three numbers are Shopify’s own advisory thresholds, not a card network’s enforcement thresholds — and conflating the two is one of the more expensive mistakes a fast-growing store makes. The app also surfaces an acceptance rate and a high-risk-order percentage, and its checkout-rules feature — filtering orders by email, address attributes or IP address — is available only to stores running Shopify Payments directly, not a separate gateway sitting in front of it.

Step 2: Automate the Risk-Level Response With Shopify Flow

Step two turns the risk level Shopify just calculated into an actual action, using the Order risk analyzed trigger in Shopify Flow rather than a person reopening every order. Shopify’s own Flow reference lists the trigger’s paired actions as Cancel order, Hold fulfillment order, Add order tags, Add customer tags and Capture payment, and ships two ready-made templates: “Cancel high-risk orders” and “Capture payment if order is not high fraud risk.”

Of the two templates, “Capture payment if order is not high fraud risk” is the one worth building first: a workflow that automatically captures payment on low- and medium-risk orders removes the delay that otherwise sits on every legitimate order while someone gets around to approving it, and routes only the high-risk share into a hold-and-review queue sized for an actual reviewer’s time. Wiring “Cancel high-risk orders” straight to automatic cancellation is the more aggressive of the two templates, and it is worth pairing with a tag rather than an outright cancel until the false-decline rate on the store’s own traffic is known, which a review of cancelled orders against later customer contacts will show.

Step 3: Set AVS and CVC Match Rules That Actually Match What They’re Named

Step three is writing address- and card-verification rules against the specific value that means a mismatch, not against “anything that isn’t a clean pass.” Stripe Radar’s post-authorisation attributes — :cvc_check:, :address_zip_check: and :address_line1_check: — return one of five values on every charge: pass, fail, unavailable, unchecked or not_provided, per Stripe’s own rules reference.

A correctly scoped rule targets the actual mismatch: Block if :cvc_check: = 'fail' or Block if :address_zip_check: in ('fail', 'not_provided') catches a real signal without touching the other three values. Rules like this run as post-authorisation checks, which is why Stripe’s documentation notes a customer’s statement can briefly show an authorisation even on a payment Radar ultimately blocks — the authorisation generally disappears within a few days once the block takes effect.

Step 4: Turn On 3D Secure for the Orders That Actually Need It

Step four is scoping 3D Secure to the orders where the liability shift is worth the friction, not requesting it on every checkout by default. Radar evaluates Request 3DS rules before any allow, block or review rule runs, per Stripe’s own rule-processing order, so a rule such as requesting 3DS only above a set order value or only when the risk level is high adds the extra authentication step precisely where it earns its cost in reduced chargeback liability, rather than on every transaction regardless of size.

3D Secure shifts liability for fraud-type disputes specifically, when the issuer supports it — it does nothing for a “not as described” or friendly-fraud dispute, because those never involve a stolen card in the first place. Running it universally trades measurable conversion friction for protection on a category of fraud that a well-tuned Radar rule set may already be catching at the authorisation stage.

Step 5: Add Velocity Rules to Catch Card Testing Before It Ships

Step five catches the fraud pattern that never looks like a completed order in the first place: card testing, where a script runs a list of stolen card numbers through small or free-shipping charges to find which ones still work. Stripe’s supported attributes include velocity counts such as the number of prior charge attempts from one card or one email within a rolling window — an hourly window covers roughly the preceding hour, counted in five-minute buckets, per Stripe’s own attribute documentation.

A rule such as blocking or reviewing a charge once the same email or card has attempted several authorisations within that hourly window catches the burst before any single attempt succeeds and becomes an order worth investigating. This is also the rule set worth checking first if a store’s decline rate spikes with no matching rise in completed orders — that mismatch is usually testing traffic, not a broken checkout.

How Much Does Fraud Actually Cost You Per 1,000 Orders at $3M–$30M in GMV?

No processor, gateway or card network publishes a representative fraud-loss rate for a $3M–$30M Shopify store, because the real rate depends on catalogue resale value, average order value and cost of goods sold — none of which any vendor knows for a specific merchant. What follows is an invented, illustrative example built to show the method, not a measured average, and every row below is calculated from the same stated inputs.

Take an illustrative store at $100 average order value, a 40% cost-of-goods ratio and an $8 shipping cost, with a fraud rate of 0.2% assumed for orders that clear screening and ship as confirmed fraud — separate from, and smaller than, a chargeback rate, since not every shipped fraudulent order results in a filed dispute.

Two things about this table matter more than the totals. First, the loss per 1,000 orders and the loaded per-order cost stay identical across both revenue bands, because both are driven by the assumed fraud rate and per-order loss, not by scale — a $30M store does not carry a lower or higher per-order exposure than a $3M one unless its actual fraud rate differs, which is the number worth measuring rather than assuming. Second, this table excludes dispute fees and evidence-assembly labour entirely, because those apply only once a chargeback is actually filed; a confirmed-fraud order that ships and is never disputed is a pure write-off of goods and shipping, a materially different number from the win-rate-adjusted dispute cost covered in the ecommerce chargebacks guide.

What Do Stripe Radar, Shopify’s Fraud Control App and Third-Party Tools Actually Cost?

Two of the tools most stores already run cost nothing, and the vendors that charge for a guarantee mostly don’t publish the rate — with one specific exception worth knowing about. Stripe includes base Radar scoring free with every account, and Shopify’s Fraud Control app is free to install for any store on Shopify Payments, per both vendors’ own documentation. The paid tier above base Radar, called Radar for Fraud Teams, is listed on Stripe’s own pricing page at $10 a month on a subscription plan or $0.05 per screened transaction pay-as-you-go, checked September 2026.

Signifyd’s own Shopify App Store listing states the app is “free to install” with charges billed separately and no rate shown, while its own BigCommerce app listing publishes a concrete Standard-tier number — the same company gates its price behind a quote on one sales channel and states it plainly on another. What Signifyd, Riskified and Kount are actually selling is also structurally different from Radar or Fraud Control: a guarantee against an approved-and-later-disputed order, reimbursed by the vendor, which Stripe’s and Shopify’s own tools score for but do not insure. That guarantee is why their real cost scales with a store’s approved order value rather than its screened-transaction count, and it is why a genuine total-cost comparison needs a quote scoped to the store’s own volume and chargeback rate before it means anything.

What Chargeback-Ratio Thresholds Actually Trigger Card-Network Consequences for a Shopify Plus Store?

The percentages inside Shopify’s own Fraud Control dashboard are not the numbers that trigger a card network’s monitoring programme — they sit well below them, which is exactly why a store can sit in Shopify’s own highest-risk band without being anywhere near a Visa or Mastercard consequence, or clear Shopify’s own bar and still be catching up to a network threshold calculated on a different formula entirely.

Crossing Shopify’s own 0.6% band changes nothing by itself; it is an internal warning, not a network filing. Crossing Visa’s or Mastercard’s actual threshold moves real cost onto the merchant account, typically from a per-case fee to a standing monthly one levied by the acquiring bank, and can lead to a reserve or account review in a sustained case — the exact fine schedule at each tier is metric to confirm, since neither network publishes a public rate card for it. A Shopify Plus store that only watches its own admin dashboard is watching the wrong ratio.

The Step Most Teams Get Wrong: Requiring a Strict AVS/CVC Pass Instead of the Value That Actually Means a Mismatch

The single most common ecommerce fraud prevention mistake is writing a rule against anything that isn’t a strict pass, rather than against the specific value that means a real mismatch. Stripe’s own rules documentation warns about this directly: “Requiring a strict pass on rules can be overly restrictive,” because Apple Pay, Google Pay and other tokenised wallets store card data with the issuer and typically return unavailable rather than pass or fail on a CVC or AVS check.

A rule written as “block unless the check equals pass” therefore blocks every wallet payment on the store, wallet fraud risk or not, because unavailable is not pass. Write the block condition against the fail value specifically instead — Block if :cvc_check: = 'fail' — so a wallet’s unavailable response passes through untouched while an actual mismatch still gets caught. Stores that discover this only after noticing Apple Pay conversion has quietly dropped are discovering it the expensive way, through lost revenue with no error message pointing at the cause.

How Do You Verify Ecommerce Fraud Prevention Setup Is Actually Working?

Verification means checking whether three numbers moved from their baseline, not confirming that the rules exist. First, the acceptance rate on Shopify’s Fraud Control dashboard: a drop here after adding rules is the false-decline cost of the new setup, and it has to be weighed against whatever fraud those same rules stopped, not read in isolation. Second, the Shopify Flow run history behind the automatic capture-and-hold workflow built on the Order risk analyzed trigger — spot-check a sample of held orders to confirm the ones flagged high risk were actually worth holding, and that low-risk orders are clearing without unnecessary delay. Third, the store’s own chargeback ratio, recalculated monthly against the Visa and Mastercard thresholds above rather than against Shopify’s own advisory bands, since that is the number an acquiring bank actually acts on.

A setup that has not moved any of these three numbers after a full billing cycle is not yet finished, whatever the rules screen shows as active.

A fraud rule that quietly blocks the wrong wallet, a chargeback ratio nobody is tracking against the threshold that actually matters, and a paid Radar tier running on its default settings are not three unrelated tickets — they are one fraud-and-chargebacks system that nobody owns end to end. Building and measuring that system, rather than leaving each piece to whoever last opened the settings screen, is the work of fraud and chargeback response systems: rules replayed against orders a store actually shipped, a renewal path for returning subscribers, and a monthly reconciliation against the ratio the card networks are actually watching. The chargeback calculator is a starting point for putting a number on what the current setup is costing before changing it.