MaShop/Journal/Tools/The Fraud Check Blocked a Real Customer. Now What?
● ToolsSeptember 26, 2026
Read · 5 min
false declines · fraud prevention

The Fraud Check Blocked a Real Customer. Now What?

Fraud models block good orders silently and log the bad ones loudly. How the scoring works, which levers a small shop can move, and the three numbers to track.

Note

This piece looks at the measurement problem behind declines. For the operational walkthrough, including dispute ratios, programme thresholds and the cheap fixes in order, see AI fraud detection and the cost of blocking a good order.

Two numbers belong in the same sentence and almost never appear there. Card fraud across the euro area ran at 0.028 percent of card payment value in 2021. Around the same time, nearly half of merchants surveyed reckoned that up to 5 percent of their legitimate orders were being turned away as fraudulent. One of those numbers is measured by a central bank. The other is a guess by the people losing the money. Neither is comfortable reading if you sell things.

Key takeaways
  • A fraud model gives every payment a score from 0 to 99. On Stripe the default thresholds are 65 for elevated risk and 75 for high risk, and only the high band is blocked automatically.
  • Actual card fraud in the euro area was 0.028 percent of card payment value in 2021, the lowest since records began in 2008, and card not present fraud was 84 percent of that total.
  • Choosing Fraudulent in the refund reason box does more than you think. It adds that email address and that card fingerprint to a block list, so a customer refunded for convenience can be barred permanently.
  • A declined good order leaves no trace in any report you normally read. A fraudulent order that got through leaves a dispute, a fee and a record. The cheaper mistake is the one you can see.
  • Your payment provider can decide to skip authentication, but the customer's own bank has the final say and can insist on it anyway.
  • A small share of the risk scores you are shown are deliberately altered so the provider can measure its own false positive rate.

How does the model actually decide?

It scores the payment against patterns drawn from every other business on the same network, then compares that score to a threshold somebody chose. Stripe's documentation on transaction risk prevention puts the score on a 0 to 99 scale and describes models that use hundreds of risk factors per payment plus data across its network, learning from purchase patterns and from feedback whenever you mark something as fraudulent.

The network effect is the part worth understanding, because it explains both the accuracy and the unfairness. Stripe states that when a business sees a card, there is a 92 percent chance Stripe has processed a payment with it before, 82 percent for a SEPA account and 71 percent for ACH. Your new customer is usually not new to the system. That is why a first time buyer at your shop can sail through, and why a perfectly honest buyer whose card was involved in somebody else's mess elsewhere can be stopped at your checkout for reasons you will never be told.

The defaults matter more than the model:

Risk levelDefault score bandWhat happens by defaultWhat you see
High75 and aboveBlocked before it reaches the networkA blocked payment, with the message that Stripe found it too risky
Elevated65 and aboveAllowed through, or sent to a review queue on some plansA successful payment flagged elevated, or an item waiting for you
NormalBelow 65AllowedAn ordinary authorised charge
Not evaluatedNo scoreAllowedNon card methods, or a shop that opted out of scoring
UnknownScoring failedAllowedA rare error state, still charged

Read the right hand column again. Four of the five outcomes end in a sale. The one that does not is also the only one where you are not told who the person was. That asymmetry is the whole subject.

What does fraud cost, next to what blocking costs?

Fraud is small and measured. Blocking is probably larger and mostly unmeasured. The European Central Bank's report on card fraud in 2020 and 2021 put fraudulent card transactions at 1.53 billion euro in 2021, or 0.028 percent of a 5.40 trillion euro total, the lowest share since collection began in 2008. Card not present fraud, which is the kind that concerns an online shop, made up roughly 84 percent of that value and fell 12.1 percent year on year.

There is a second finding in that report that a small exporter should copy down. Cross border transactions were 63 percent of total card fraud value while being only 11 percent of card payment value. Fraud is concentrated in orders crossing a border, which is exactly where a growing shop wants to sell.

Against that, the decline side. PYMNTS reported that 47 percent of merchants say false declines cost them sales, with nearly half estimating up to 5 percent of legitimate orders wrongly refused and an industry figure of 50 billion dollars in lost revenue. The same piece reports 85 percent of merchants naming their top challenge as stopping fraud without spoiling the customer experience.

Now the honest part, which most write ups of these figures skip. Those two sets of numbers are not the same measurement. The central bank figure is fraud as a share of payment value across a currency area, audited and published. The merchant figure is a share of orders, self estimated, from a survey whose sample size, dates and methodology the article does not disclose. You cannot subtract one from the other and get a profit. What you can say is that the measured cost of fraud is a fraction of a percent of value, while the estimated cost of over blocking is talked about in whole percentage points of orders. When the two sides of a tradeoff are known to that different a standard of proof, the side with no evidence is the side that quietly wins.

Comparison diagram weighing a blocked good order against an accepted fraudulent order, showing which of the two leaves a record you can review

Why the cheaper mistake is the one you can see

A fraudulent order that gets through announces itself. There is a dispute, a fee, a notification, a deadline and a line in a report. It hurts, it is countable, and at the end of the quarter you can say what it cost, assuming you know which evidence a chargeback representment actually needs.

A good order that got blocked does none of that. The shopper sees a failure message that does not explain itself, assumes your shop is broken or that their card is, and goes elsewhere. No dispute is raised because no sale happened. In most dashboards it appears as a blocked payment among other blocked payments, indistinguishable from the ones that deserved it. If you measure only what generates paperwork, you will optimise towards blocking forever, because blocking is free in the only ledger you read.

This is the same trap as a support bot whose success metric is tickets closed rather than problems solved, and it has the same fix: count the thing that does not complain. Your block rate is a number your provider can show you. Watch it monthly. A shop that runs at 2 percent blocked in March and 6 percent in November has either attracted a crime wave or broken its own checkout, and the second is far more likely.

The refund reason box is a block list in disguise

This is the single most expensive click in the interface, and nothing in the interface says so. Stripe's documentation states that refunding a payment with Fraudulent selected as the reason adds the email address and the card fingerprint of that payment to the default block lists. Not to a review queue. To a block list.

Consider how that happens in a real shop. A customer disputes a charge they simply forgot about, or a family member used the card, or an order went wrong and you want the dispute to go away cheaply. Selecting Fraudulent feels like the tidy administrative choice, and it is also a permanent judgment about a person and a card. That card may belong to a good customer. It may be the card of a household where three people share one payment method. The block is silent and has no expiry that the box mentions.

The useful rule is small and worth writing on a note beside the screen. Fraudulent is for the cases where you believe the cardholder did not authorise the purchase. Everything else, including every refund you grant to keep the peace, is a normal refund with a normal reason. The same discipline that keeps an automated refund decision from crossing into rights a customer legally holds applies to the label you attach to it afterwards.

Note

The reverse of the block list exists too. Stripe lets you add a blocked payment to an allow list, which stops future attempts from that payment method or email being blocked. It does not retry the payment that failed, so the sale in front of you is already lost. Allow listing is for keeping the customer, not for saving the order.

Who has the final say, you or the customer's bank?

Their bank. You can tune your side of the decision as much as you like, and the card issuer can still overrule it. The European Banking Authority's answer on the transaction risk analysis exemption makes the allocation explicit: each payment service provider may apply the exemption based on its own fraud rates regardless of the others, and the payer's own provider keeps ultimate authority to accept or decline an exemption and can require strong customer authentication anyway.

In plain terms: a provider can judge a payment low risk and try to wave it through without an authentication step, and the shopper's bank can insist on the step regardless. A shop that has spent a month removing friction from its checkout does not control the last gate, and no amount of tuning will hand it over. The ECB report notes that market wide authentication rolled out by the end of 2020 appears to have notably increased the security of card not present transactions, which is the trade every online shop is now inside whether it chose it or not.

The practical consequence is about expectation setting rather than engineering. If your checkout sometimes throws a bank verification screen at a returning customer for no reason you can see, that is not your bug. It is worth a sentence on your help page saying so, because the alternative is a customer who concludes your shop is unreliable.

Some of the scores you are shown are wrong on purpose

Buried in the same documentation is a sentence that changes how much weight a single score deserves. For a small subset of payments, Stripe says it modifies the reported risk score in order to measure its own model performance and gather data for future development, specifically so metrics such as false positive rate and recall stay within desirable ranges.

That is a defensible thing for a provider to do. A model that only ever sees the outcomes of its own decisions cannot learn what it got wrong, which is the classic blind spot of any system allowed to act on its own predictions. But it does mean the number attached to one payment is not a verdict. It is a sample from a process that is partly experimenting on you.

So do not build a policy around a single score, and be careful about the story you tell yourself when one order scores 71 and another scores 74. Patterns across a month are evidence. One score is an observation. The same caution applies to every other automated judgment landing on a small business, including the model that scores your own application for credit, where the score you are shown and the reasons you are given are also not the whole system.

What can a one person shop actually change?

More than you would expect, and none of it requires a fraud team. The documentation lists four actions a rule can take: request authentication, allow, block, or send for review. Most shops only ever use two of them, and the cost of the ones they do use shows up twice, since every failed attempt also carries an authorisation charge on the processing statement where three separate fees arrive as one percentage.

LeverWhat it doesWhen it earns its keep
Request authentication instead of blockingPushes the decision to the cardholder's bank rather than refusing the saleMid value orders you would hate to lose, where a verification screen is better than a dead end
Review queue on elevated riskHolds the order for a human instead of auto decidingLow volume, high value goods, where reading one order costs less than losing it
Allow list for known customersStops repeat blocks on a person you have already verifiedAny customer who has bought before and got stopped once
Correct refund reasonsKeeps genuine customers out of the block listsAlways, and it costs nothing but attention
Separate rules for cross border ordersConcentrates strictness where fraud actually isAny shop shipping abroad, given that cross border was 63 percent of fraud value

One thing not on that list is raising the block threshold across the board because a good customer complained. That trades a known small loss for an unknown larger one, and it is the reflex that produces a bad quarter three months later. Change one lever, watch one month, keep the record.

Illustration card naming the three decline numbers a small shop should track, the block rate, the dispute rate and refunds marked as fraud

What about subscriptions and saved cards?

They behave differently, and the difference is easy to miss. Stripe states that for recurring billing the fraud models score only the initial payment of a subscription, while rules are evaluated on every payment. So the model's judgment is made once, at signup, and inherited by every renewal afterwards.

For a subscription business that is mostly good news, because a customer is not re-tried against a fraud model every month. It also means a bad initial decision follows the customer for the life of the subscription, and that the failures you see on renewals are usually issuer declines rather than fraud blocks. Those are a different problem with a different fix, closer to the mechanics of recovering a sale that did not complete than to fraud prevention.

Worth noting too: the documentation is explicit that risk settings and the controls covering fraudulent disputes and early fraud warnings do not use the main models at all. They run on separate, more specialised models built to balance authorisation against fraud. So the thing labelled fraud protection in your dashboard is not one system with one dial. It is several, and they do not necessarily agree.

Where the responsibility lands

With you, and the provider says so in the first paragraph. Stripe's documentation states plainly that you are ultimately responsible for the payments you choose to accept, including those later disputed or found fraudulent. That sentence is the reason none of this can be fully delegated. A vendor supplies a probability. The loss is yours either way, whether it arrives as a chargeback or as a customer who never came back.

Which is why the three numbers on the card above are worth more than any tuning session. Your block rate, your dispute rate, and how many refunds you have marked as fraudulent this year. The first two together tell you whether you are strict or loose. The third tells you how many real people you may have quietly barred. Nobody sends you that report, and a shop that owns its own checkout and database can produce it in an afternoon from records it already holds, which is a better position than asking a platform for a metric it has no reason to volunteer.

The uncomfortable summary: fraud is a small, well measured, insurable cost, and over blocking is a large, badly measured, uninsurable one. Most shops spend their attention on the first because it sends letters.

Discussion 0

0 / 4000Your email address is not displayed with your comment.
No comments are published yet.

Explore — related articles.

Build something. Move your work forward.

Start with a software project or an agent task. Describe the result you need, review the work and keep control of your connected accounts.

Open the workspace →