Ecommerce Fraud and Chargeback Software: What Are Your False Declines Really Costing?

Fraud loss is the number everyone manages, and it is the wrong one

Here is the meeting that happens in every retailer above a certain size. The risk lead presents a chargeback rate of 0.28 percent, down from 0.34, and everyone nods. Nobody in the room can say what the decline rate did over the same period, or what those declined orders would have been worth, or how many of them were repeat customers who have not come back. The fraud team is measured on a number it can always improve by declining more, and the cost of that improvement lands in a different department's report.

The three costs sit on one profit line and they trade against each other. Fraud loss, which you see. Chargeback fees and network monitoring exposure, which you see. And false declines, which you almost never see, because a good customer who gets refused at checkout does not email you, they buy from someone else and quietly stop being your customer. On a large book, a fraction of a percentage point of decline rate is worth more than the entire fraud loss line, which is precisely why this is worth building rather than renting.

The tooling most retailers run is a guarantee vendor like Signifyd, Riskified or Forter for the approve or decline call, the payment provider's own basic rules, a spreadsheet for the review queue, and a chargeback specialist like Chargebacks911 handling representment. Each piece is competent. What none of them holds is a single object that knows this customer's five year order history with you, their return rate, their support tickets, the delivery outcome on their last three parcels, your contribution margin on this specific basket, and what happened when a dispute on their previous order was represented. That object is the whole game.

The decline threshold belongs to your margin, not to a vendor's loss ratio

The guarantee model is genuinely useful and it is honest about what it is: the vendor takes liability for approved orders in exchange for a fee per order. That structure has one consequence people underweight. The vendor is optimising their own loss ratio, not your contribution margin. They cannot see that a $60 order on a 55 percent margin product is worth approving at a risk level that would be reckless on a $900 order at 12 percent, because they do not know your margins and would not price on them if they did.

The result is a single global threshold applied to a catalogue with wildly different economics. Your highest margin, lowest fraud-attractiveness categories get declined at the same score as your resale-friendly electronics. On top of that, the guarantee fee is charged on all approved volume, including the overwhelming majority that was never at risk, which is why the economics invert as you scale.

What a custom build does: the decision is a business calculation, not a score. Expected value of approving equals expected margin multiplied by probability of good, minus expected loss multiplied by probability of fraud, where expected loss includes the goods, the shipping, the chargeback fee and the handling time. Set the threshold per category, per fulfilment method and per customer tenure. Then a first-time buyer of a high-resale-value item on express shipping to a freight forwarder gets treated completely differently from a five year customer buying a replacement filter, and neither judgement requires a human. Publish the resulting approval rate by segment to your commercial team monthly, because the moment merchandising can see which categories risk is declining, the conversation changes from fraud loss to profit.

Representment is an evidence assembly problem before it is a dispute problem

A chargeback arrives six to eight weeks after the order, with a reason code, a short issuer narrative and a response deadline. To fight it you need the order record, the AVS and CVV results, the device and IP evidence from checkout, the carrier's proof of delivery with signature or geolocation, prior undisputed orders from the same customer, the customer service transcript, and the terms the customer accepted. Those sit in six systems. A human assembles them into a PDF, and the deadline passes on the ones nobody got to.

The reason codes matter more than most teams treat them. A fraud dispute in the card-absent environment is a fundamentally different argument from a merchandise-not-received dispute, which is different again from not-as-described. The evidence that wins each is different, and card network rules have moved toward structured evidence for repeat-customer fraud claims, with Visa's compelling evidence provisions being the most visible example. Network rules change, so build the templates as configuration a risk analyst can edit, not as code a developer must redeploy.

What a custom build does: the moment a dispute lands from the acquirer's API, the system assembles the evidence pack automatically against a per-reason-code, per-network template, calculates the expected win probability from your own historical outcomes for that code and issuer, and either files it or routes it to a human when the value or the uncertainty justifies attention. The economics are simple. Below a threshold, representing costs more in analyst time than the recovery is worth, so accept and move on. Above it, always fight. Your current process probably has that logic reversed, because the low value disputes are quick to handle and the big ones are intimidating.

The data a vendor cannot see, and the abuse that is not really fraud

A large share of what retailers book as fraud is not a stolen card. It is policy abuse: serial returners, wardrobers, refund-claim abusers who report every third parcel missing, and discount stacking through repeated account creation. Payment fraud tools score the transaction, so by construction they cannot see a pattern that only appears across a customer's lifetime of orders, returns and support tickets.

This is the argument for owning the risk layer that nobody makes strongly enough. Your own history is the highest-signal data available and it never leaves your business. Concretely, useful features include return rate by customer relative to their category, the ratio of not-received claims to deliveries, address clustering where multiple accounts ship to the same unit, the interval between account creation and first high value order, and support contact patterns before a dispute. None of that is available to an external scoring API in a form that means anything.

The right response is rarely a decline. It is a policy: this customer no longer gets free returns, or their orders require signature on delivery, or refunds are issued after the item is received rather than on the claim. Building a graduated response ladder, instead of a binary approve or decline, is where retailers recover the most money with the least customer damage.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the honest shape is this. A first release covering the decision engine trained on your order history, a rules layer your analysts can edit, a review queue with proper case handling, and automated representment packs for your top reason codes runs $65,000 to $140,000 and ships in 12 to 16 weeks. A full platform adding retraining pipelines with proper labelling from chargeback outcomes, policy abuse detection, issuer-specific evidence templates, network monitoring alerts and a merchant analytics view runs $160,000 to $400,000 phased over 6 to 12 months.

What pushes cost up here: the number of payment providers and acquirers, because each dispute API and file format is a separate integration and their webhooks disagree about state. Multi-region, since European traffic under strong customer authentication has a different liability picture and needs different logic. Marketplace or multi-seller structures, where liability allocation is a whole extra design. And label quality, which is the quiet one: if your historical chargeback outcomes were never written back to the orders that caused them, you have no training data and the first phase becomes a data reconstruction job.

What keeps cost down: starting on one region, one payment provider, and your two highest volume dispute reason codes. That covers the majority of the disputed value and proves the model before you widen it.

When a guarantee vendor is still the right answer

Buy if your annual volume is under roughly $20M, if your chargeback rate is comfortably under 0.3 percent, or if you genuinely value the balance sheet certainty a guarantee provides more than the margin it costs. There is nothing wrong with paying someone to take a risk you do not want. Signifyd, Riskified and Forter are all credible and their models see cross-merchant patterns yours never will, which is a real advantage against organised card testing.

Build when two or more of these are true. Your guarantee fees now exceed what a small risk engineering team costs. Your decline rate is unknown or unmanaged and merchandising has started asking about it. Your margin varies widely across the catalogue and a single threshold is visibly wrong. Your losses are increasingly policy abuse rather than stolen cards. Or you are approaching a card network monitoring programme threshold and need to move your rate deliberately rather than by asking a vendor to tighten. The tipping point is not technical. It is that at scale the risk threshold is a pricing decision, and pricing decisions should not sit outside your business.

How to choose a developer for a fraud and disputes build

Ask how they will label training data. The correct answer includes writing chargeback outcomes back to the originating order, handling the six to eight week delay before a label exists, and being explicit that orders you declined have no outcome at all, which is the sample bias that ruins naive models. A developer who does not raise that problem unprompted has not built one of these.

Ask what they will do about explainability. Every decline needs a human-readable reason, both for your support team when a customer calls and for the analyst tuning the rules. A model that outputs a score and nothing else will be overridden into uselessness within a quarter.

Ask which acquirer and dispute APIs they have actually integrated, by name. Adyen, Stripe, Braintree, Worldpay and Chase Paymentech expose disputes differently, with different evidence field limits and different submission windows, and experience with one does not transfer.

Ask who owns the models, the feature store and the code, and put it in the contract before kickoff. Your order history is the asset that makes this work and it should never sit in someone else's account. At Digital Heroes the client owns the repository from the first commit, and any developer who resists that is building a hold over you rather than a system for you.