October 20, 2026 · Shawn Kelley, Co-Founder & CEO
When I ran payment and risk ops at SeatGeek, we looked hard at building our own chargeback management system but ultimately decided against it. These are the reasons I'd give any team weighing the same call.
The live event industry had a strange COVID (as did we all, let's be real). For a couple of years there were almost no live events and therefore pretty much no sales, so fraud nearly disappeared. But everyone wanted their money back for events that were postponed, then rescheduled, then eventually canceled. Our systems were built to take money in, not to send it out en masse. We suddenly needed to do some major re-engineering to handle huge volumes of refunds while still managing cashflow, all while the non-fraud chargebacks kept coming in on the same events. As you can imagine, those chargebacks became a massive issue and forced us (multiple times) to rethink how we approached all of it.
During COVID and before it, we had worked with a few different chargeback vendors. One was a nightmare from a billing and invoicing standpoint. Another was good at automating, but when I needed to lean on them to help us navigate the mess during COVID, it quickly became apparent that automation was where their knowledge was. They couldn't help us strategically figure out how to handle the massive changes, and they couldn't help facilitate the conversations that needed to happen with the card networks. Those conversations did eventually happen, thanks to the team at Ticketmaster using their leverage.
I needed a vendor that understood our business, knew chargebacks deeply and could help us do better. Nobody in the market I met with felt like the kind of partner we were looking for. That's how building our own dispute system came up. And you'd think, with everything I just mentioned, we would've built it ourselves.
The biggest reason was that chargeback management wasn't our core mission.
Every engineer and product person working on disputes would have been pulled off the work the company existed to do. You can always run the analysis and weigh the cost, and for us it didn't come out in favor of building.
The other reason was maintenance.
A tech-forward approach to chargebacks needs work long after it's built, because chargebacks keep changing. Network rules, processor requirements, what issuers accept and what you need to accurately represent (and win) a case all move, and a system that stops keeping up quickly falls behind. Anything we built, we'd be maintaining for as long as we took card payments. I encounter large enterprise teams all the time who are using tools built for them during a hackathon. Amazing, shiny, new and efficient. Then never maintained, and slowly the manual work creeps back in to bridge the gaps.
We also meet teams who tell us they can build templates in-house and auto-fill them. Easy. Right?
You can do that, and filling in a template is the easiest part of responding to a chargeback. Not long ago I saw another vendor bragging that they had 250 templates to handle nearly every type of dispute, reason and product. You can even use AI now to crank out those 250 templates in an afternoon. The hard part is keeping them correct as the rules move. Small changes mount up quickly and now you have a document management mess to maintain. Not to mention, what if you realize (as you should) that not all disputes should be fought? And what if you want to understand what's driving your chargebacks in the first place, in a way that helps you receive fewer of them?
A template system does none of that, and every template you add is one more thing someone has to keep current.
The other path is people. That's not only a common path, it's one we strongly considered.
Ideally, someone would look at every chargeback, work out what happened and why, then handle it the way it needs to be handled. That usually means going into multiple systems during the investigation and then again to assemble the evidence for the representment. At scale, that just isn't possible, so teams take shortcuts by combining templates and people. Then you have to accommodate seasonality, and live event ticketing has a lot of it. Staff for the peak and the team sits idle in the trough. Staff for the trough and the peak buries them.
So what happens instead, in my experience, is that companies fall back to fighting everything with a basic approach. They win some cases that were real fraud, which means the customer whose card was stolen is the one who ends up paying. They win many of the non-fraud cases they should win. They also win some they shouldn't.
Fighting everything looks productive. What it costs you is the fees on every case you lose, the wins you had no business getting and any understanding of why the chargebacks happened in the first place. You never get a real chance to be in control of what happens next.
Here's the part that stuck with me from that vendor search.
My usual way to find a provider is to ask other merchants. For every other part of the fraud and payments stack, I could find merchants who'd tell me who they used, that they loved them and that I should go talk to them.
Dispute management was the only vertical in the stack where I couldn't get that kind of referral for anyone. Nobody was telling me they had a dispute vendor they loved, one that was crushing it for them.
That gap is where Disputed started.
I wanted the vendor I couldn't find at SeatGeek. I also wanted one that wouldn't make me fight everything, so we could treat customers fairly and use each chargeback to learn what was going wrong upstream.
Doing that root-cause work on every chargeback takes technology, because no team can staff its way there.
There's always a case for building, and I've talked with teams who brought disputes in-house for cost savings and more control. I think it can work when these things are true.
If you're making this call right now, I'm happy to compare notes, whichever way you end up going.