Overheard at PaymentsEd: Everyone's Fighting the Same Data Problem

We spent a few days last week at PaymentsEd Forum, and if there's one thing that came up in nearly every session—from alternative payment method adoption to return fraud to retry strategies—it's that payments teams are drowning in data they can't actually use.

The pattern was impossible to miss. Merchants have a data problem with no clear and easy solutions. Payments data is scattered across PSPs, siloed by function, and inconsistent enough that "apples-to-apples" comparison is more aspiration than reality.

The Real Cost of Scattered Data

Multi-PSP routing decisions depend on comparing processors against each other, and that comparison only holds up if you're looking at equivalent slices of traffic. Sending one processor your retries that already failed elsewhere, or routing only your highest-risk transactions to one PSP, means you're comparing different customer segments and risk mixes, not the processors themselves.

In practice, almost no one sends identical volume to every PSP. What actually matters is being able to segment your data after the fact, pulling out the same customer segments and payment method mix from each processor so you're comparing like with like. That's only possible with harmonized data: decline codes normalized so a "do not honor" means the same thing across every processor, metrics calculated the same way regardless of which PSP produced them. Without that, you can still route traffic across PSPs, but you have no reliable way to tell which one is actually performing better.

Alternative payment methods, network program changes like CEDP and DCAP, virtual cards; the landscape keeps shifting, and each shift changes what merchants need to track and how to interpret it. Every one of these problems traces back to the same gap: no unified, trustworthy layer connecting what's happening at the transaction level to the decisions merchants actually need to make. Plenty of teams have already thrown real resources at this—building internal pipelines, hiring data engineers, stitching together spreadsheets—and still end up frustrated: too slow, incomplete, full of inconsistencies, and a constant time-sink to maintain.

Bad Data Breaks AI Too

Once you have good data, the work isn't done, it needs to be watched closely enough to catch problems before they cost you. A monthly snapshot only shows you what already happened. Real monitoring means normalized data watched continuously, so you catch a shift while there's still time to act on it.

Merchants trying to do this with AI run into a wall. Even the best model hits the same wall the moment the underlying data is fragmented or unnormalized. No model can compensate for bad inputs, and no model replaces the need to actually monitor what's happening.

From Data to Decisions

Talk after talk validated the bet we've made at Pagos: the next competitive edge in payments isn't a better dashboard or a smarter model bolted onto messy data—it's clean, connected, transaction-level data that teams can actually trust and act on. Whether it's routing, cost, fraud, or retry strategy, the merchants making real progress are the ones who've stopped treating data cleanup as a side project and started treating it as a core capability.

Once you can see a shift, the next question is whether it's actually about you. A dip in approval rate could be something you changed, something your PSP changed, or just market conditions moving for everyone at once, and you can't tell the difference without knowing what your peers are seeing. That's why benchmarking is the last step from good to great: it turns "our approval rate dropped" into "our approval rate dropped, and here's why."

If your team is still stitching together auth and decline data by hand across processors, that's the visibility gap Pagos closes. Connect your processors and accurately compare performance, see where approval rates shifted, or catch where you're paying too much in fees. Whether you're looking at it directly or plugging Pagos into your own LLM workflows via MCP, either way, you see it the moment it happens, not weeks later in a spreadsheet. That's the problem we spend every day solving. Let's talk.