Magento Fraud: What Moves the Number and What Is Noise

Magento fraud is the catch-all a store owner types when a chargeback, a stolen card or a suspicious order shows up — but the term covers at least three different problems that respond to different fixes, and the pages ranking for it mostly sell one extension as the answer to all three. Adobe Commerce and Magento Open Source ship with no fraud screening switched on; whatever catches a bad order depends entirely on which gateway and which extension a merchant has actually installed, which is a genuinely different starting point from a platform where a fraud tool is bundled into checkout by default.

Where Does Magento Fraud Actually Come From?

Three mechanisms account for most of what a Magento store’s dashboard calls fraud, and they need three different responses. Card testing is a bot running a list of stolen card numbers through small, cheap or free-shipping orders to find which ones are still live before using them somewhere larger — it shows up as a burst of failed or declined attempts, not a shipped order, and the fix is rate-limiting and velocity checks at the gateway rather than anything downstream. Account takeover is a fraudster logging into a real customer’s saved account with credentials stolen elsewhere and placing an order against saved payment details or store credit — the checkout looks legitimate because the account is, and a rule built to catch a stranger’s mismatched billing address misses it entirely. Friendly fraud is a genuine cardholder disputing a real, correctly delivered order instead of contacting the merchant, and it produces a chargeback with no fraud signal anywhere in the checkout to have caught.

The Magento-specific wrinkle is where the signal for card testing, account takeover and friendly fraud each actually lives. On a platform with one native payment method, fraud data sits in one place. On Magento, a store might run Braintree, Adyen, Authorize.net or Stripe as its gateway, plus a separate extension — Signifyd, Riskified, Kount or a marketplace tool such as Amasty’s — layered on top, and each of those systems logs its own version of the order. A chargeback ratio calculated from the gateway’s dashboard and a fraud score calculated by the extension are two different numbers watching two different windows into the same order, which is exactly the kind of split that a store owner assumes is reconciled and usually isn’t.

Why Doesn’t Tightening the Screening Rules Lower a Magento Store’s Chargeback Rate?

Tightening screening rules lowers a chargeback rate only for the share of chargebacks that screening was ever capable of stopping, and on most stores that share is smaller than the rule-writer assumes. A screening rule works at the moment of checkout, deciding whether to approve, decline or hold an order based on the signals available then — address mismatch, device fingerprint, velocity, a risk score from whichever tool is installed. Friendly fraud happens after that moment entirely: the order was genuine, it shipped correctly, and the dispute is filed weeks later by the same cardholder who placed it. No screening rule, however tight, has a lever on a chargeback that originates after a real customer’s own decision to dispute a real purchase.

What tightening does move, reliably, is the false-decline rate — good customers refused because a rule flagged a legitimate signal as risky. A rule is written the day a specific fraud pattern is noticed, gets credited for every order it blocks afterward, and is almost never checked against how many of those blocked orders were actually fraud versus a customer whose billing address just didn’t match their delivery address that month. Rules accumulate in one direction because nobody is measured on the revenue a rule refuses, only on the fraud it appears to catch — so a screening configuration tightened repeatedly over several years typically has more rules quietly costing sales than rules still earning their place.

What Do We Build Instead, and What Does It Cost to Run?

What we build instead treats every active screening rule as a classifier and measures it like one, rather than trusting the rule’s own log of what it caught. Every rule currently live in whichever tool a store runs — Stripe Radar, Signifyd, Riskified or a gateway’s built-in scoring — gets replayed against a year of orders the store actually shipped, producing a confusion matrix: which orders the rule correctly flagged as fraud, which orders it wrongly refused, and which fraud it missed entirely. A rule that has only ever refused good customers and never once caught a fraudulent order comes off. This mechanism is not Shopify-specific — it needs a store’s order history and its screening tool’s decision log, not a particular cart platform, and the same replay-and-measure method applies unchanged whether the screening sits in front of Braintree on Magento or Stripe on Shopify.

Alongside rule replay, we also build a returning-customer path that scores repeat buyers on their own delivered history rather than the signals a first-time stranger is judged by — three prior orders delivered clean and paid without dispute is evidence a rule built for first-time checkouts has no field for. Rule changes then run in shadow mode before going live: scoring every order without acting on any of them, so what a proposed rule would have blocked gets checked against what actually shipped and got paid for, before it costs a single real sale.

Running the rule-replay and shadow-mode system ongoing is not free, and naming what it costs is part of giving a straight answer rather than a pitch. The build itself runs $4,000–$10,000, scoped as one project alongside any payment-recovery work happening at the same time, because both draw on the same order and dispute data. Ongoing rule-tuning and case-filing work is arranged separately, priced against the dispute volume it actually sees rather than a flat retainer, because a store filing four cases a month and a store filing forty need different amounts of that work.

What Does a Chargeback Actually Cost a $3M–$30M Magento Store, Per Order?

The real per-order cost is — metric to confirm — no gateway, extension or card network publishes a representative figure across catalogues, because the answer moves with average order value, cost of goods and a store’s own dispute rate, none of which any vendor knows for a specific merchant. What can be shown is the method and how it scales across the $3M–$30M band, using assumed, clearly invented inputs rather than a claimed average.

Take an illustrative Magento store at $120 average order value, a 40% cost-of-goods ratio and a $9 shipping cost, with a $20 dispute fee assumed for the gateway (real dispute fees are set in a store’s own processor agreement and are not a published industry figure — Stripe’s own pricing update shows a $15 fee as one data point among several possible structures, so $20 here is a stand-in, not a quote). A lost chargeback carries no return process the way an ordinary refund does — the goods already shipped are gone along with the payment — so the unrecovered cost per lost chargeback is $48 cost of goods plus $9 shipping plus $20 dispute fee, which is $77.

Two things about the per-order cost table are worth reading past the totals. First, the per-order loaded cost stays identical at $0.31 across both revenue bands, because it’s driven by the assumed chargeback rate and per-case cost, not by scale — a $30M store doesn’t pay a lower or higher rate per order than a $3M one unless its actual dispute rate differs, which is the number worth measuring rather than assuming. Second, this table shows the unrecovered cost, not a win-rate-adjusted one — how many of these are winnable depends on the reason code and the evidence a store can actually produce, and no general win rate is safe to assume, which is why the unrecovered-exposure figure in the table is a floor rather than a forecast.

Does Manual Order Review or Automated Risk Scoring Cost Less at Scale?

Manual order review and automated risk scoring neither wins outright — the crossover depends on a store’s flagged-order volume, not its total order volume, and that volume is something a store can measure for itself in a way no vendor’s pricing page can answer generically. The labour half of that comparison can be built directly from a store’s own numbers: take the number of orders a screening tool actually flags for manual review in a month, divide by how many a reviewer can realistically work through in an hour, and multiply by a loaded hourly wage.

On the same illustrative $120-AOV Magento store used for the per-order cost table, assume the gateway’s scoring flags 6% of orders for manual review, a reviewer clears 15 flagged orders an hour, and the loaded wage is $30 an hour. At $3M in revenue (25,000 orders a year, roughly 2,083 a month), 6% is 125 flagged orders a month, needing about 8.3 reviewer-hours, at a monthly labour cost near $250. At $30M in revenue (250,000 orders a year, roughly 20,833 a month), 6% is 1,250 flagged orders a month, needing about 83.3 reviewer-hours, at a monthly labour cost near $2,500 — the labour cost scales linearly with order volume because a person reviews orders one at a time regardless of how many the store processes.

Automated-scoring pricing is the side of manual-review-versus-automated-scoring no vendor publishes a rate card for — Signifyd, Riskified and Kount price against a store’s actual volume and risk profile in a negotiated quote, not a public per-transaction fee, so that half is — metric to confirm — the method is to request pricing scaled to the store’s own flagged-order volume (125 to 1,250 flagged orders a month across the $3M–$30M band, from the reviewer labour calculation), ask specifically whether it’s charged per transaction or as a percentage of gross merchandise value, and ask about any monthly minimum. What decides the crossover is not “does automation cost less” in the abstract; it’s whether the quoted automated fee at a store’s actual flagged-order volume falls below the reviewer labour cost calculated for that same volume, which a store can only know once both numbers are in hand.

How Should a Magento Store Choose a Fraud Approach Without Pitching One Extension?

The choice between manual review, a rules engine and a machine-learning scoring tool turns on five things that have nothing to do with which extension a vendor is selling: order volume against the labour-versus-automation crossover, how close a store already runs to the Visa and Mastercard chargeback-ratio thresholds, how much of the catalogue is high-resale-value (electronics, gift cards, limited releases — the SKUs card-testing fraud actually targets), whether checkout needs a real-time approve-or-decline decision or can tolerate an overnight batch review, and whether the tool offers a financial guarantee against approved fraud or just a score with no liability shift.

Visa’s merchant-level Acquirer Monitoring Program threshold tightened to 1.50% of card-not-present volume from 1 April 2026, and Mastercard enrols a merchant in its Excessive Chargeback Program at a 1.50%–2.99% ratio combined with 100 to 299 monthly chargebacks — both measured against the merchant account processing the transactions, not the storefront platform in front of it. A store already running near either threshold has less room to accept the false-decline cost of over-tightened manual rules than one running well under it, which is a genuinely different starting position from a store choosing on catalogue risk alone. The full mechanics of both ratios, including the exit conditions and what an acquirer does once a store crosses either line, are worked through in the ecommerce chargebacks guide rather than repeated here.

Choosing between manual review, a rules engine and a machine-learning scoring tool is not an extension-selection problem once the criteria are separated from the pitch — it’s a fraud-and-chargebacks systems problem. The mechanism that actually moves a Magento store’s chargeback number is measuring what the current rules catch and cost, not adding another one on top, which is the work we build as part of fraud and chargeback response systems — rule replay against a store’s own order history, a returning-customer path the default rules don’t have, and shadow-mode testing before any change touches a live checkout.