Payment Intelligence Platforms and Providers

Search that term today and most of what comes back is about getting payments approved: failed payments, false declines, retries, recovered subscriptions. That work is real and the companies doing it are good at it, because an approval that never happens is revenue that never arrives.

The transaction that succeeds is not finished, though. It carries a cost that lands days later in a settlement file, and for a vertical SaaS platform sitting above hundreds of merchants that is where the margin lives. It is also the half of the category almost nobody has built for.

What is a payment intelligence platform?

A payment intelligence platform reads payment data from outside the systems that produced it and interprets what that data says about money the business is losing. The category divides by which side of the authorisation it works on. One half works up to approval: declines, retries, acceptance, tokenisation. The other works after it: what the transaction cost, whether the fees charged match the agreement, which characteristics set the rate, and which merchants in a portfolio earn less than they cost to serve. Both halves read the same transactions and ask different questions of them.

Working the second half means reading processor and scheme reporting (fee lines, settlement and clearing detail, and transaction characteristics such as MCC, card category, scheme, and amount) and joining it to the platform’s own software data: which merchant, which product, what the transaction was. It does not need cardholder data, because the attributes that drive cost are categorical rather than personal.

The interpretation is what separates this from reporting. Reporting gives you the number: your effective rate last month was 2.31%. Intelligence tells you what sits behind it. Part of that rate is structural, set by your card mix, your geographies, and the categories your merchants trade in, and no amount of work moves it. Part of it traces to a data problem, a rating-relevant field arriving missing or malformed, and that can be fixed. And part of it is real, correctly identified, and still out of reach. Telling those three apart is the work.

That third category is the one nobody expects. Business cards carry higher interchange, and what qualifies them for better rates is Level 2 and Level 3 data: the extra purchase fields, tax amount, purchase order, line-item detail, that commercial transactions have to carry. An integration can be built to send those fields. If the provider does not support them, the fields go out and nothing changes: the finding is correct, the opportunity is real, and the value of acting on it is zero. The useful answer then is not a better interchange analysis. It is whether those transactions belong on that rail at all, and what it would take to make ACH the obvious choice for the merchants sending them. You only get to that question by establishing the first one is closed.

Why the blended number is usually wrong

Query access used to be the constraint, since the developers who built the integration were the only ones who knew where the data sat. Natural-language tools removed that, and the answers still disagree: three teams ask what looks like the same question and get three different numbers, all technically correct. The platform’s database was never where payment cost lived, so there are two problems rather than one, assembling the processor reporting into something joinable and then knowing which question to put to it. Only the first tends to get budgeted for.

A platform asks for margin across the portfolio. The query runs correctly. A number comes back. It is an average, and averages across a portfolio hide the segment you would actually act on. Merchants with negative margin do not show up as a loss, they show up as slightly weaker average performance, absorbed by the healthy majority.

Take platforms that let end users add a tip at checkout. On many of them the tip is where the platform’s own margin sits, so when the tip is smaller than the fees on that transaction, the platform loses money processing it. To identify which transactions were tipped at all, you have to cross-reference payment data against the platform’s software data, usually through metadata. If the database was not organised with that join in mind, and the team asks for portfolio margin without the tips dimension, the result is not slightly imprecise. It describes a business that does not exist.

The effective rate is usually incomplete for a second reason. Most platforms build their number from the two fee lines that arrive labelled, the discount rate and the per-transaction fee. Whether the platform bears the other fees at all depends on the commercial model, which a query cannot infer: a platform acting as merchant of record carries the cost and earns the spread, while one earning a revenue share on merchants who hold their own MIDs is looking at a different number entirely, and processor reporting rarely makes it obvious which fee belongs in which bucket, so assignment is a judgment call before it is a calculation. None of that is fixed by better SQL.

Who is building payment intelligence platforms?

The term is claimed by five kinds of company that mean different things by it. That is the main reason a buyer cannot tell which of them to call.

Independent intelligence layers. Pagos is the clearest example, built on the premise that a cross-platform view reveals what a single provider’s reporting cannot. It normalises data across processors, monitors it continuously, and benchmarks anomalies against the customer’s own history and the industry.

Reconciliation-native. Optimus (optimus.tech) comes at the same data from reconciliation, validating interchange qualification at transaction level to surface downgrades and billing errors, then analysing profitability by merchant, MCC, and acquiring type. That origin puts it closest to portfolio-level economics, because reconciliation always had to work record by record rather than in aggregate.

Analytics with consulting. Optimized Payments pairs its Harmonize software with consultants, and its published work includes implementing Level 2 and Level 3 data to reduce downgrades. They understand interchange mechanics as well as anyone in the market, and deliver that judgment through people.

Orchestration-native. Orchestration platforms were built to route and manage payments across providers, and what separates them is mostly which part of that job they optimised for, from credential portability at one end to depth in a single vertical at the other. Several have added reporting on top of the routing layer, and it sits where their data sits, at the transaction and authorisation level, where approval rates and retry behaviour live. Cost is decided one layer down, in the settlement files that arrive after the fact.

Processor-native and network-native. Stripe, Adyen, Checkout.com, and PayU all offer intelligence over their own processing, from acceptance optimisation through to fee reporting that breaks interchange and scheme costs out at transaction level, and Visa and Mastercard work at network altitude with peer benchmarking. Each sees the volume it handles, which is a design fact rather than a shortcoming, though it does mean a platform running more than one provider ends up with several good pictures and no single view across them. The other thing to check is your own pricing model. Stripe states that its cost reductions apply to accounts on custom interchange pricing, while most SaaS accounts sit on a blended flat rate where one number covers both the card cost and the processor’s margin. Under a blended rate, an interchange improvement does not move what you pay.

Grouped that way the field is less crowded than it looks, because nearly all of it was built for a merchant analysing its own volume or a bank analysing its own rails.

Where the category line actually falls

Almost nothing on that map competes with the rest of it. A vertical SaaS platform will run several at once, because they sit at different points in the same journey. Merchants get boarded and priced. Transactions authorise at checkout, where the orchestration and processor layers work. Days later the settlement files arrive and say what those transactions cost. Money moves out, and reconciliation matches what landed against what was owed. Every stage has good tools built for it, and a platform is right to buy them.

The gap is at the end of that sequence. Once the files have arrived and the payouts have cleared, someone still has to answer which merchants are making money, which are not, and what can be done about it. That needs the processor’s data joined to what only the platform knows: which merchant, which product, whether the transaction carried a tip, what the platform charged for it. No layer in the journey owns that join, because each was built to do its own job well and none sees both sides.

We built Flexibl for that gap. It reads the data after settlement, joins it to the platform’s own software data, and works merchant by merchant rather than across a blended portfolio, alongside the rest of the stack rather than in place of any of it. It is the interpretation layer between capture and finished analysis, the part that decides what an outcome means and whether it can be moved. The vantage across many platforms is what makes recurring causes recognisable rather than investigated from scratch.

FAQ

What does a payment intelligence platform actually do? It reads data from processors and schemes, joins it to the operational data that explains each transaction, and interprets why costs landed where they did. The output is a judgment about what is structural, what is fixable, and what is real but unreachable.
How is payment intelligence different from payment analytics? Analytics presents the numbers the underlying data already contains. Intelligence adds interpretation: what a cost outcome traces back to and whether it can be changed. The gap shows up the first time a correct number leaves you with nothing to act on.
Does payment intelligence require access to cardholder data? No. Cost outcomes are driven by categorical attributes such as merchant category code, card category, scheme, and amount band, none of which identify a cardholder. Scoping the work to those attributes and to aggregates is what keeps it outside PCI scope.
Who are the payment intelligence providers? They group into independent intelligence layers such as Pagos, reconciliation-native platforms such as Optimus, analytics-plus-consulting firms such as Optimized Payments, orchestration platforms that have added reporting, and processor-native and network-native offerings from Stripe, Adyen, Checkout.com, PayU, Visa, and Mastercard. Flexibl sits in the independent layer, built for platforms rather than single merchants.

Related reading: what payment margin leakage is, [what processor contract drift costs], and [what causes interchange downgrades].

If you want to see this against your own portfolio, we run the analysis merchant by merchant rather than blended. Request a walkthrough.