Ecommerce Fraud and Chargeback Software Problems: The 7 That Cost You Good Orders, and How to Avoid Them

Why does tightening the rules keep making the business worse?

The structural problem is the scoreboard. The risk team is measured on chargeback rate and fraud loss, both of which can always be improved by declining more, and the cost of that improvement lands on a different department's report. So every quarter the rules tighten a little, the chargeback rate improves a little, and nobody in the room can say what the decline rate did, what those declined orders were worth, or how many were repeat customers.

This is a scoping failure before it is a modelling one. A project briefed as reduce chargebacks will produce a system that reduces chargebacks. A project briefed to maximise contribution margin across approvals, fraud loss and dispute costs will produce something different, because it has to know your margins and it has to report on the trade off rather than one side of it.

The fix is to make the decision a business calculation rather than a score threshold. 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 thresholds per category, per fulfilment method and per customer tenure, so a first time buyer of a high resale item on express shipping is treated differently from a five year customer buying a replacement part.

Then publish approval rate by segment to your commercial team monthly, alongside fraud loss. The moment merchandising can see which categories risk is declining, the conversation stops being about fraud and starts being about profit, which is the conversation that should have been happening all along.

What goes wrong with your historical order data and training labels?

This is where these projects actually slip, and it is almost never in the plan. A model needs orders linked to their eventual outcomes, and in many retailers chargeback outcomes were never written back to the originating order. The disputes live in the acquirer's portal, the orders live in your commerce platform, and the join between them was a human reading a reference number. Reconstructing that across two years of history is a data project, and discovering it in week three has already eaten the schedule.

The second problem is subtler and ruins models built by people who have not done this before. Your historical data only contains outcomes for orders you approved. The ones you declined have no outcome at all, so the training set is a sample selected by your existing policy, and a model trained on it learns to reproduce that policy rather than to improve on it. It will look excellent in validation because it agrees with the decisions that generated its own training data.

The third is the delay. A label does not exist until a dispute arrives, typically six to eight weeks after the order, so recent data is unlabelled and any evaluation that ignores this overstates performance.

The fixes are known and should be in the proposal. Write dispute outcomes back to orders permanently, starting now, regardless of what else you build. Approve a small random sample of orders above your decline threshold so you generate outcomes in the region you cannot currently see. Evaluate on time based splits, and never on a period where labels are still maturing.

Why do acquirer and dispute integrations break after launch?

Every payment provider exposes disputes differently. Adyen, Stripe, Braintree, Worldpay and Chase Paymentech disagree about state names, evidence field limits, file formats, attachment size and submission windows, so experience with one transfers only partially to another. A build that integrated two of them has not learned a general pattern, it has learned two specific ones.

After launch the recurring breakages are consistent. Webhooks arrive out of order or twice, so a dispute that was already represented gets picked up again, or a state transition is missed and a case sits in the queue past its deadline. Evidence documents that were accepted last quarter start being rejected because a field limit changed. And card network evidence rules themselves evolve, with the structured evidence provisions for repeat customer fraud claims being the most visible example, so a template that won cases last year quietly stops working.

The fixes are unglamorous. Treat webhook handling as idempotent by design, keyed on the dispute identifier and the event, so duplicates are harmless and order does not matter. Reconcile daily by listing open disputes at each provider and comparing to your own. Put a deadline monitor on every open case with escalation before expiry, because a missed deadline is an automatic loss. And build evidence templates as configuration a risk analyst can edit, since network rules change on their timetable rather than yours.

What happens when policy abuse is not covered at all?

A large share of what retailers book as fraud is not a stolen card. It is serial returning, wardrobing, repeated claims that parcels never arrived, and discount stacking through fresh accounts. Payment fraud tools score a transaction, so by construction they cannot see a pattern that only exists across a customer's lifetime of orders, returns, claims and support contacts.

When this is left out of scope, two things happen. The abuse continues, because the transaction looks perfectly normal every single time. And your fraud numbers become misleading, because losses that are actually policy failures get categorised as fraud, which sends you back to tightening rules that will never touch the cause.

The signals that matter here are all in data you already own and no external scoring service can see in any meaningful form: return rate relative to the norm for that category, the ratio of not received claims to deliveries, address clustering where several accounts ship to the same unit, the interval between account creation and a first high value order, and support contact patterns immediately before a dispute.

The response is rarely a decline, and this is the part teams get wrong, because declining an abusive but paying customer removes the revenue along with the abuse. The right response is a graduated ladder: no more free returns, signature required on delivery, or refunds issued after the item is received rather than on the claim.

Should you build custom or configure what you already own?

Under roughly twenty million in annual volume, or with a chargeback rate already comfortably below a third of a percent, stay with a guarantee vendor and spend the money on acquisition. Signifyd, Riskified and Forter are credible, and their cross merchant visibility is a genuine advantage against organised card testing that your own data will never match. Paying someone to take a risk you do not want to hold is a legitimate commercial choice, not a failure of ambition.

Before commissioning anything, check what you are actually not getting from what you already pay for. Many retailers have never asked their guarantee vendor for segment level approval rates, never tuned the categories where they take the most declines, and never negotiated the fee structure against their approved volume. Those conversations are free and sometimes resolve the complaint.

The same applies to disputes. If representment is the pain, a specialist such as Chargebacks911 handles process and template knowledge that is genuinely expensive to build, and for a retailer with modest dispute volume that is the right trade.

Build when the economics have inverted. Guarantee fees charged on all approved volume, most of which was never at risk, now exceed what a small risk engineering team costs. Your margins vary widely enough across the catalogue that a single global threshold is visibly wrong. Your losses are shifting from stolen cards toward policy abuse a transaction scorer cannot see. Or you are approaching a network monitoring threshold and need to move your rate deliberately rather than by asking a vendor to tighten.

How do hidden costs get into the quote?

The first is provider count. Each acquirer and payment provider is a separate dispute integration with its own formats, limits and windows, and each is separate maintenance thereafter. A quote covering one provider is not a quote covering three.

The second is label reconstruction, discussed above, which is the single most common reason these projects run long. Ask the developer to inspect your dispute to order linkage before quoting rather than after, and expect a different number if the linkage does not exist.

The third is region. European traffic under strong customer authentication carries a different liability picture and needs different logic, and a build scoped for one market and then extended is close to two builds.

The fourth is marketplace or multi seller structure, where liability allocation between you and your sellers is a design problem in its own right and is frequently discovered halfway through.

The fifth is review tooling. Manual review is a small part of volume and a large part of the interface, and a usable case view needs full order context, customer history, prior disputes and a required reason on every override. Skimp on it and analysts work in spreadsheets beside the system you just bought.

What separates a build that works here from one that fails?

Every decision carries a human readable reason. Support needs it when a customer calls, analysts need it to tune, and you need it when a merchandising director asks why their category is being declined. A model that emits a score and nothing else gets overridden into uselessness within a quarter, because people do not defer to systems they cannot interrogate.

The review band is set by expected value rather than by score. An analyst reviewing a seventy dollar order costs more than the expected loss on it, so most orders should never reach a human, and the ones that do should be selected because the value at stake justifies the attention.

Representment is driven by economics rather than instinct. Below a value threshold, fighting costs more analyst time than the recovery is worth, so accept and move on. Above it, always fight. Most retailers have this reversed, because small disputes are quick and large ones are intimidating.

Overrides require a written reason and feed back into the rules, because without that loop the model and the humans drift apart and nobody can explain the system's behaviour a year later. And ownership of the models, the feature store and the repository sits with you, because your order history is the asset that makes any of this work.