- Visa's merchant threshold fell to a 1.5% ratio in April 2026, but it only bites at 1,500 combined fraud and dispute records, which most small shops will never reach.
- The party that actually polices a small merchant is the acquirer, whose own excessive threshold is 0.7% and who can restrict or close your account.
- Signifyd cites a global average false decline rate of 1.51% of ecommerce sales, while 38% of merchants in the MRC survey report between 2% and 5%.
- A loyal customer who gets falsely declined orders 65% less often afterwards, and 27% never come back at all.
- Stripe deliberately alters the reported risk score on a small subset of payments so it can measure its own false positive rate.
Every guide about card fraud is written for the merchant losing money to fraud. For a small shop the more likely problem is the opposite one, and it is invisible in a way fraud never is. Fraud shows up as a chargeback with a reason code and an email. A blocked good customer shows up as nothing at all.
That asymmetry is why so many small sellers tighten their filters after one bad week and never find out what it cost them. The chargeback you prevented is countable. The four people who tried to pay, got declined, and bought elsewhere are not in any report you receive.
Who is actually watching your dispute rate?
Your acquirer, not Visa. The card network's programme has a floor that most small businesses sit well below, while the acquirer has commercial reasons to act on you long before that floor is reached.
The mechanics changed recently enough to be worth restating. Visa folded its separate dispute and fraud monitoring programmes into a single Acquirer Monitoring Programme, and the ratio it computes is reported fraud plus disputes divided by total sales, counting only card not present transactions. Both halves of that numerator matter: a TC40 fraud report from an issuer and a TC15 non fraud dispute land in the same place, so a customer who simply forgot what they ordered counts the same as a stolen card.
The Merchant Risk Council notes that the excessive merchant threshold dropped from 2.2% to 1.5% on 1 April 2026, with acquirer tiers set at 0.5% for above standard and 0.7% for excessive, and a fee of $8 per fraud or dispute notification once a merchant is enrolled. First time violations get a three month grace period.
Now the part that reframes the whole thing for a small seller. Those thresholds carry a minimum of 1,500 combined TC40 and TC15 records. A shop doing a few hundred orders a month is not going to produce 1,500 disputes in any timeframe that matters. You are, in the network's terms, invisible.
That is not the relief it sounds like. Your acquirer is measured on its own portfolio, and its excessive threshold is 0.7%. If your dispute rate is dragging their aggregate number up, they do not need Visa to enrol you before acting. Restrictions, reserves and account termination are all available to them, and the smaller you are the cheaper it is for them to simply stop working with you.
| Ratio | Who it applies to | Threshold | Minimum count | What it means for a small shop |
|---|---|---|---|---|
| VAMP merchant, excessive | Individual merchant ID | 1.5% from April 2026 | 1,500 combined records | Rarely reachable, so rarely the real constraint |
| VAMP merchant, CEMEA | Merchants in that region | 2.2% | 1,500 combined records | Same practical point, higher bar |
| VAMP acquirer, above standard | Your processor's portfolio | 0.5% to under 0.7% | 1,500 combined records | Where pressure on you originates |
| VAMP acquirer, excessive | Your processor's portfolio | 0.7% or higher | 1,500 combined records | The number your processor is defending |
| Enumeration ratio | Card testing attacks | Separate measure | Enumerated over total sales | Matters if your checkout is being probed |
The practical instruction that falls out of this table is not "stay under 1.5%". It is: ask your processor what their threshold for concern is, because that is the number governing your account, and it is lower.
What does a false decline actually cost?
More than the fraud it prevents, for most shops. Signifyd cites Datos Insights putting the global average false decline rate at 1.51% of ecommerce sales, and the Merchant Risk Council's 2026 fraud report finding 38% of merchants self reporting rates between 2% and 5% of orders, with two thirds between 2% and 10%.
Sit with the gap between those two numbers, because it is instructive. The measured average is 1.51%. The self reported figures are mostly two to five times higher. Both cannot describe the same thing, and the likeliest explanation is that merchants who look closely find more than the ones who do not. A shop that has never checked is not a shop with a low rate. It is a shop with an unknown one.
The cost is not only the order. Signifyd reports that a loyal customer, defined as somebody with three or more approved orders behind them, places 65% fewer orders after a false decline, spends 16% less per order, and in 27% of cases never returns. Your best customers are also the ones who take it most personally, which makes sense: they had no reason to expect it.
Nobody emails you to say they were declined. They assume their card has a problem, or that your site is broken, and they leave. The only trace is a payment attempt that failed and a session that ended. If you have never gone looking for that pattern in your payment dashboard, you have never seen your own false decline rate.
How does the scoring actually decide?
By a number between 0 and 99, produced by a model trained across a whole network of merchants rather than on your shop alone. Where the cut sits is a setting, and the default is not tuned for your business.
Stripe's documentation is unusually specific about this. Radar assigns each payment a risk score from 0 to 99, and by default a score of 65 or above is elevated risk while 75 or above is high risk. High risk payments are blocked automatically. Elevated ones are allowed by default and can be routed to a review queue instead.
Two details in that documentation deserve more attention than they get. The first is scale: Stripe states there is a 92% chance it has already seen a given card somewhere in its network. That is why network based scoring beats anything a single small merchant could build, and it is also why the model knows things about your customer that you do not.
The second is stranger and more useful. Stripe says that for a small subset of payments it modifies the reported risk score, so it can measure the performance of its models and keep metrics such as false positive rate and recall within desirable ranges. Read plainly: a holdout group exists, and some payments are scored differently from how the model would score them, because measuring a fraud system requires letting through things it wanted to block. Every serious fraud product does some version of this. Almost no merchant knows it is happening on their account.
Why does the default threshold not suit you?
Because the cost of a wrong block and the cost of a wrong approval differ enormously between businesses, and a default cannot know yours. A shop selling digital downloads at $9 and a shop selling furniture at $1,200 should not sit at the same cut off.
Work it out in the only terms that matter, which are yours. For a wrongly approved fraudulent order you lose the item, the shipping, the transaction fee, the chargeback fee, and a mark on your ratio. For a wrongly blocked order you lose the margin on that sale plus, on Signifyd's figures, a large slice of that customer's future ordering. If your average order carries thin margin and your customers rarely repeat, blocking aggressively is defensible. If you sell high margin goods to people who come back, it is expensive.
The threshold is a business decision expressed as a number, and it is one of the few settings in a payment stack where the correct value genuinely depends on you. Treating it as a technical default somebody else chose is how shops end up insulting their best customers to prevent a fraud loss smaller than the margin they gave up.
Where do the disputes actually come from?
Not mostly from stolen cards, on a typical small shop. The larger share is people disputing purchases they genuinely made, for reasons ranging from confusion to regret to a deliberate attempt to keep the goods and the money.
This matters because the two problems have opposite remedies. A stolen card is stopped at authorisation by scoring, authentication and address checks. A customer disputing their own order is not stopped by any of those, because the payment was legitimate when it happened. It is stopped earlier, by describing the product accurately, or later, by evidence at representment.
A shop that responds to a rising dispute rate by tightening its fraud filter, when the disputes are coming from its own customers, gets the worst available outcome. The dispute rate does not fall, because the filter cannot see those transactions coming. The decline rate rises, so revenue falls. Then the tighter filter looks like it is working because total order volume dropped and disputes dropped with it, in proportion. Diagnosis first, settings second.
The way to tell them apart costs nothing. Dispute notifications carry a reason code. Sort a quarter of them into two piles: the ones claiming the cardholder did not authorise the transaction, and everything else, which covers not received, not as described, duplicate charges and subscription cancellations. The ratio between those piles tells you which problem you have, and therefore which of the fixes below is worth your weekend.
What does the dispute process cost even when you win?
Time and a fee you generally do not get back. The chargeback fee is charged when the dispute is filed rather than when it is decided, so a successful defence still leaves you out of pocket and out of an afternoon.
That changes the arithmetic on fighting them. Below some order value it is rational not to contest at all, and the correct response is to work out what that value is for you rather than defending everything out of principle. Above it, the deciding factor is whether you kept the evidence at the time. Nobody wins a dispute on indignation.
There is also a quieter cost in the ratio itself. Because the numerator counts disputes filed rather than disputes lost, winning does not repair your standing with your processor. A merchant who successfully defends every dispute still carries the same ratio as one who loses them all. Prevention and representment are different activities, and only the first one moves the number that gets your account reviewed.
What should you actually measure?
Three numbers, all of which you can get from a payment dashboard without buying anything.
Your dispute ratio, computed the way Visa computes it. Fraud reports plus disputes over settled card not present sales, in the same month. Not chargebacks over revenue, which is a different and flattering number. Knowing your own figure means you can answer your processor rather than be told.
Blocked payments that later succeeded. Signifyd lists this as the primary way organisations find false declines: orders that go through on a retry and never produce a chargeback were, by definition, good orders you refused the first time. If your processor lets you search declined payments by risk level, this is a ten minute exercise.
Repeat rate after a decline. Take the customers who hit a block in a given quarter and check how many ordered again. Compare against your overall repeat rate. This is the number that turns an abstract false positive into a figure you feel.
Should you mark a refund as fraudulent?
Only when it genuinely was, and understand what the button does before you press it. In Stripe's case, refunding with the reason set to fraudulent adds that email address and card fingerprint to your default block lists, which means the decision is not just about this order.
The temptation is to use it for anybody who disputes a charge, including the customer who genuinely forgot and the one whose partner used the card. Those cases are common and they are not fraud. Marking them as fraud trains the model on a false label and permanently blocks somebody who might have kept buying from you. It is a small button with a long memory, which is exactly the kind of control worth being deliberate about, in the same way we argued for care around what an automated system is allowed to do without asking.
What about orders placed by an AI shopping agent?
They look anomalous to a fraud model, and this is becoming a real source of false declines. An assistant completing a checkout produces patterns that historically meant automation and therefore meant risk: fast form completion, unusual navigation, sometimes a mismatch between the browsing context and the payment details.
Signifyd's own list of recommendations now includes integrating AI agent metadata to distinguish authorised shopping agents from fraudulent activity, which is a quiet acknowledgement that the old signal has broken. Speed at checkout used to be evidence of a bot, and a bot used to mean fraud. Now a bot may be a customer's assistant buying something on their behalf with their permission.
For a small shop the immediate action is modest: know that this category exists, and do not conclude from a run of odd looking declined orders that you are under attack. It matters more if that traffic is growing for you, and it is growing for a lot of shops. We looked at the size and behaviour of that channel when Adobe found AI referred shoppers converting better than other retail traffic, which makes blocking them an expensive mistake to make twice.
The cheap fixes, in order
Most dispute reduction has nothing to do with fraud tooling. It is description, expectation and evidence, in that order.
Make your billing descriptor recognisable. A large share of disputes come from customers who do not recognise a line on a statement. If your descriptor is a company name nobody has heard of, change it to the shop name they actually bought from. This is a settings change and it removes disputes rather than fighting them.
Set delivery expectations in writing, then over communicate. Disputes filed as item not received frequently arrive from customers who simply had no idea where the parcel was. The same proactive notification work that reduces support tickets reduces disputes, which is why the two projects should be done together rather than sequentially. The triage logic for that queue is in our piece on which support tickets a small shop can safely automate.
Keep evidence you can actually submit. Delivery confirmation, the terms the customer agreed to, the correspondence. Representment succeeds on documentation, not on argument, and gathering it after the dispute arrives is always harder.
Turn on the free authentication controls. Address and CVV verification cost nothing and remove a whole class of dispute. Strong customer authentication shifts liability for many transactions, which is worth understanding for the categories where you carry the most risk.
Is a dedicated fraud tool worth it at small volume?
Usually not as a separate purchase, because the scoring built into your payment processor already draws on network data you could never assemble. What is worth doing at any volume is reading the settings rather than accepting them, checking your own false decline rate, and knowing your processor's tolerance.
The moment a dedicated tool starts making sense is when you can state a specific problem it solves that your processor's scoring does not: a category with unusual risk, a market where your decline rate is much worse, a fraud pattern you can describe. Buying one because fraud feels frightening produces a subscription and a tighter filter, which is the combination most likely to cost you money quietly.
One structural point underneath all of this. Every control discussed here lives in your payment stack and your own site: the descriptor, the notification emails, the checkout flow, the evidence you keep. Shops that can change those things quickly can respond when a threshold moves, as one did this April. Shops waiting on a platform release cannot, which is the everyday argument for owning the storefront you sell through rather than renting it. Payment rules change on the card networks' schedule, not on your platform vendor's.