What chargeback management software actually does (and where the money goes)

Chargeback management software sits between your payment processor and your order data, pulling together transaction records, shipping confirmations, and customer communication into evidence packets, then submitting them to fight disputes before they turn into lost revenue plus a fee. The category is dominated by a handful of names: Chargeflow, Riskified, Signifyd, Accertify, and Chargebacks911. Nearly all of them price the same way: a percentage of whatever they recover, typically 15 to 30 percent, or a flat per-case fee if you lose regardless of outcome.

That pricing model is the whole story of this post. It makes sense when your dispute volume is low and unpredictable. It stops making sense once volume, processor count, and the value of your own transaction history all grow past a point where the software's 20 percent cut is bigger than the cost of owning the logic yourself. Nobody selling you the tool is going to tell you where that line is. We've diagnosed enough finance and ops teams drowning in SaaS line items to know the line exists, and it moves earlier than most founders expect.

Why buying makes sense at low volume

If you're processing under a few hundred disputes a month on a single processor, buy the tool. This isn't a hedge, it's the honest answer. At low volume, the fixed cost of building your own evidence-compilation pipeline (data engineering, processor API integration, ongoing maintenance as scheme rules change) dwarfs whatever percentage you'd hand over to a vendor.

A merchant doing $2M a year in revenue with a 0.3% chargeback ratio is dealing with maybe 50 to 150 disputes a month. Paying a vendor 20 percent of recovered revenue on that volume is still cheaper than one engineer's salary spent building and maintaining a dispute pipeline nobody else at the company understands. This is the same logic that applies across every build-vs-buy decision we've seen in accounts receivable and procurement automation: rent until the rented thing's cost curve crosses your own build cost curve, then stop renting.

The honest case for buying also holds when you're single-processor, single-currency, and your fraud patterns are simple enough that the vendor's generic model performs fine. Most early-stage e-commerce and subscription businesses fit this description. Don't let anyone talk you into a custom build at this stage. It's the wrong fix for a problem you don't have yet.

At what dispute volume does chargeback management software break down?

The breakdown isn't a single number, it's a set of signals that tend to arrive together, usually after a PE roll-up, a multi-brand expansion, or a jump into a second payment processor. Watch for these:

• Multiple processors or entities. Once you're running Stripe, Adyen, and a legacy processor from an acquired brand simultaneously, a single vendor's dashboard stops giving you one picture. You're now paying three different revenue-share percentages to reconcile data that should live in one place.

• Multi-currency, multi-region exposure. US and EU dispute rules diverge (different card scheme timelines, different consumer protection regimes), and most off-the-shelf tools handle one region well and the other as an afterthought.

• You need dispute data feeding your own fraud model or CRM. If your data science team wants transaction-level dispute outcomes to retrain a fraud model, a third-party SaaS tool that holds your evidence data behind an API you don't control becomes a bottleneck.

• The revenue-share math stops making sense. At $50M in annual revenue with a healthy chargeback ratio, even modest dispute volume can mean six figures a year flowing to a vendor that's running the same evidence-matching logic you could own.

Run the math yourself before you decide anything. Take your trailing twelve months of chargeback volume, multiply by your average recovered amount, multiply that by the vendor's percentage. If that number is higher than what it would cost to run a lean internal system with one engineer and a quarterly compliance review, you've outgrown the point tool. This is the same threshold logic we laid out for accounts receivable automation once invoicing complexity outpaces a single tool, and it shows up almost identically here.

What Visa Compelling Evidence 3.0 and Mastercard's rules mean for your build/buy decision

Compelling Evidence 3.0 is the scheme rule that makes owning your dispute data genuinely valuable once you have enough transaction history to use it. CE 3.0 took effect April 15, 2023, and applies specifically to Visa reason code 10.4, the card-absent fraud dispute, often called "friendly fraud" (Checkout.com's breakdown of the rule). To win under CE 3.0, a merchant has to show at least two prior undisputed transactions from the same cardholder, dated 120 to 365 days before the disputed transaction, matching on at least two of: account login ID, shipping address, IP address, or device fingerprint, with at least one of IP or device required. The billing descriptor's first six characters also have to match.

Visa's own "one year later" data on CE 3.0 shows meaningful dispute deflection for merchants who implemented it well (Verifi's follow-up report), and the scale of the underlying problem explains why. Merchant Fraud Journal estimated disputes were set to cost merchants roughly $100 billion in 2023 (cited via Payments Consulting), a figure worth treating as directional rather than precise, since it's a secondary estimate, but the order of magnitude is real.

Here's the part vendors don't advertise: CE 3.0 rewards merchants who have deep, clean historical transaction data more than it rewards merchants who've bought the best dispute software. A vendor's generic model is matching against whatever data you hand it through an integration. A system built on your own order, login, and device data, with direct access to 120 to 365 days of history, can match CE 3.0's criteria more precisely because it isn't working through someone else's API abstraction layer. Once a merchant has enough historical volume to make that precision pay off, the case for owning the evidence-matching logic gets stronger every quarter.

What Regulation E and Regulation Z require if you handle disputes in-house

If you're a bank, fintech, or anyone issuing cards or managing ACH transfers, the compliance stakes are higher than scheme rules, they're federal regulation, and this is where "augment" often beats "full build." Regulation E, the CFPB's rule under the Electronic Fund Transfer Act, governs consumer disputes on debit and ACH transactions and generally requires provisional credit within 10 business days while an investigation is ongoing (12 CFR 1005.11). Miss that window and you're not just losing a dispute, you're in regulatory violation territory.

Regulation Z, enforced under the Fair Credit Billing Act, is the credit-card-side counterpart: consumers have a 60-day window from the statement date to dispute a charge, and cardholder liability is capped at $50 (FTC's guidance on the FCBA). For a pure e-commerce merchant fighting friendly fraud, these rules matter less directly, your processor and the card networks handle most of the regulatory burden. But for a fintech or bank building its own dispute resolution flow, Reg E and Reg Z timelines are hard deadlines baked into the architecture, not best practices.

This is exactly where we tell clients to augment rather than build from scratch. Compliance logic around provisional credit timing, documentation retention, and consumer notification is well-trodden ground, and getting it wrong carries real regulatory exposure. Pair a vetted compliance layer with a custom evidence and automation layer built around your own transaction data. Full build makes sense for the parts of the system that are genuinely proprietary to your fraud patterns. It doesn't make sense for reinventing Reg E timers.

Build, buy, or augment: a decision framework

We walk every client through the same four questions before recommending anything, and the answers usually point in one direction without much debate once they're laid out honestly:

• Dispute volume and recovered-revenue size. Under a few hundred disputes a month, buy. Several hundred to a few thousand with a single processor, buy or augment. Thousands a month across multiple processors or entities, build or augment heavily.

• Number of processors and entities. One processor, one entity: a SaaS tool's dashboard works fine. Multiple processors after an acquisition or multi-brand rollout: you need a unified data layer regardless of who's running the evidence logic, which already starts looking like a build.

• In-house data and fraud capability. If you already have a data team maintaining a fraud model, the dispute evidence pipeline is a natural extension, not a new discipline. If you have none, augmenting a vendor's tool with better internal data feeds beats a ground-up build.

• Regulatory exposure. Pure e-commerce chargebacks: scheme rules only, build is more viable. Bank or fintech-issued cards and ACH: Reg E and Reg Z exposure pushes toward augmenting a compliance-vetted base rather than building the regulatory logic from zero.

The pattern we see most often in mid-market companies ($5M to $50M in revenue) is augment: keep a compliance-tested base for the regulatory timers, and build the evidence-compilation and processor-submission layer in-house once dispute volume justifies it. Full build is rare below $50M in revenue unless disputes are a core part of the business model itself, like a chargeback-insurance company or a high-risk-vertical payment processor.

What a custom dispute-automation system actually looks like

A custom build isn't a bigger version of the SaaS dashboard, it's an agent that sits closer to your own data than any third-party tool ever will. The pattern we've built for clients automating similarly document-heavy, deadline-driven workflows looks like this: an agent pulls order history, shipping confirmation, login and device records, and prior transaction data directly from your internal systems, matches it against the relevant scheme rule (CE 3.0's two-data-point requirement, for instance), compiles the evidence packet in the format the processor expects, and submits it through the processor's API, flagging only the cases where confidence is low or data is missing for human review.

That last part matters more than the automation itself. The goal isn't to automate every dispute end to end, it's to automate the 80 percent of disputes with clean, matchable data and let a human handle the ambiguous ones. We've built the same confidence-threshold pattern for document-heavy intake and case-assignment workflows in other regulated settings (Genta AI Solutions has shipped exception-based automation for medical-legal case intake with a similar "autopilot unless low confidence" design, documented in our Preferred Med Network case study), and the pattern holds here: full automation claims always leak accuracy somewhere, and the honest system tells you where.

The financial case is straightforward once you've built it: you keep 100 percent of recovered revenue instead of handing 15 to 30 percent to a vendor indefinitely, and the evidence-matching logic improves every quarter as your historical transaction data deepens, which a rented tool's generic model can't do for you specifically.

If you're working through this decision, this is exactly what Genta's Discovery phase maps out before anything gets built, diagnosing dispute volume, processor complexity, and regulatory exposure against the real cost of what you're currently renting. Compare notes with us on what an owned dispute-automation system would look like for your volume if the revenue-share math isn't working anymore.

Frequently asked questions

What is Visa Compelling Evidence 3.0 and do I need software to use it?

CE 3.0 is a Visa scheme rule, effective April 15, 2023, that lets merchants fight card-absent fraud disputes (reason code 10.4) by showing two prior undisputed transactions matching on data like IP, device, shipping address, or login ID. You don't need special software to use it, you need clean, matchable historical transaction data and a way to compile it into the required format, which is what both SaaS tools and custom systems do differently.

What are the three types of chargebacks?

Chargebacks generally fall into three categories: true fraud (the cardholder's account was compromised), merchant error (wrong item, billing mistake, failure to deliver), and friendly fraud (the cardholder disputes a legitimate charge, often forgetting the purchase or disputing instead of requesting a refund). Friendly fraud is the category CE 3.0 was built to address.

How much does chargeback management software cost?

Most vendors charge 15 to 30 percent of recovered revenue, or a flat per-case fee regardless of outcome. There's rarely a flat license fee or ownership path, it's a recurring revenue share that compounds as your recovered-dispute volume grows, which is the core economic reason merchants eventually outgrow the model.

What's the difference between dispute management software and chargeback management software?

"Chargeback management" usually refers to consumer card disputes on e-commerce transactions. "Dispute management software" is a broader category that also includes B2B accounts receivable deduction tools (like HighRadius, see their automated dispute management product) and bank-side Regulation E and Z compliance tools. Companies growing across e-commerce and financial services often need to understand all three.

At what dispute volume does it make sense to build a custom chargeback system instead of buying one?

There's no single number, but the signals cluster around a few thousand disputes a month across multiple processors or entities, combined with enough historical transaction data to make evidence-matching precise, and an in-house data or fraud team that can maintain the system. Below that, buying or augmenting a vendor's tool is almost always cheaper.