What I look for when I diligence a payments platform

Most technical due diligence on a payments company is diligence on a software company that happens to move money.

The questions are competent and generic: cloud architecture, test coverage, security posture, technical debt, key dependencies, engineering headcount against roadmap. All of it matters. None of it is where payments companies actually fail.

A payments platform fails in payments-specific ways, and those failures are close to invisible to a reviewer who has not run one. They do not show up in a quality-of-earnings report. They show up eighteen months after close, as an integration that costs three times the estimate, a partner payout dispute nobody can reconstruct, or a platform migration that quietly consumes the value-creation plan.

Here is what I look at instead.

Start by reconstructing one transaction

Before any document review, I ask for a single transaction — ideally one the company had to investigate — and ask the team to walk it end to end: authorization, capture, batch, funding, settlement, the merchant's deposit, the partner's residual.

Then I count how many systems and how many people it took to answer.

This one exercise surfaces more than a week of document review. If reconstructing a transaction requires a person who knows where to look, the platform does not have a source of truth; it has a set of records that usually agree. Everything downstream — reporting, reconciliation, dispute evidence, the numbers in the data room — inherits that uncertainty.

The good version takes one query and one person. I have seen the bad version take four systems, two spreadsheets, and the only analyst who understands the funding file.

Settlement: look for manual adjustment, not for errors

Every payments company will tell you settlement is accurate. Most can support that claim, because errors get caught and fixed.

The question that matters is how.

I ask what the month-end close looks like in practice. Specifically: how many manual adjustments are made, who makes them, and whether anyone could re-run the period from raw processor files and land on the same number.

Manual adjustment is the single best proxy for platform health in a payments business. A settlement layer that reconciles only after human intervention is not a system; it is a system plus a person. That person is a key-man risk that never appears on the key-man risk slide, the labor cost scales with volume in a way the model assumes it will not, and the moment they leave, the accuracy leaves with them.

Ask for the exception rate rather than the error rate. Companies track errors because errors are visible. Exceptions are where the labor actually goes, and they are usually not counted at all.

Residuals are the most under-examined liability in the business

In merchant acquiring, partner and ISO residual calculation gets less scrutiny in diligence than almost anything else of comparable financial consequence.

It should not. Residuals are a contractual obligation, computed monthly, across tiered and negotiated terms that accumulated over years, usually in logic that predates most of the current team. If the calculation cannot be re-run and audited, the company has an obligation it cannot prove it has met.

I ask three questions. Can you recompute last quarter's residuals from source and match what you paid? How many partner agreements have terms that exist only as an exception in code? When a partner disputes a payout, how long does it take to answer, and what does the answer rest on?

A buyer who inherits an unauditable residual engine has bought a dispute they cannot win, and they will not find out until a partner asks.

Integration count is a vanity metric

Every payments company advertises its integrations. The number is nearly meaningless in isolation.

What matters is composition. For each processor, gateway, and acquiring relationship, I want to know whether the integration is genuinely productized — configuration on a common framework — or bespoke, with its own exception handling, its own certification history, and its own quirks that live in someone's head.

Two useful tests.

How many could you turn off? A platform where any integration can be disabled without incident is a platform with real abstraction. One where the answer is "it depends which one" has accumulated coupling nobody has mapped.

How many does more than one person understand? Ask who would handle a certification issue on each connection at two in the morning. If several names repeat, you have found the actual constraint on the integration roadmap, and it is not budget.

This is where migration estimates go wrong. The plan assumes integrations are units of work. In practice a handful are units of work and the rest are archaeology.

Underwriting: is the policy written, or is it resident in judgment?

The instinct is to look at the pend rate. It is the wrong first question, because it can mislead in both directions.

A high pend rate means underwriting is a throughput ceiling: headcount is the only growth lever, and sales velocity is capped by review capacity. That is a real problem and an obvious one.

A low pend rate can be worse. It may mean risk policy is being under-applied rather than automated. Always read the pend rate against the loss rate and the chargeback profile; a queue that moves fast because nobody is looking is not efficiency.

The question underneath both is whether risk policy exists as a stated, testable rule, or as accumulated analyst judgment. Policy that lives in judgment cannot be audited, cannot be consistently applied, cannot be defended to a sponsor bank, and cannot be automated — because you cannot automate a decision nobody has written down.

That last point is where most automation programs stall. They start with the model. Every one I have seen work started with the rules: make the implicit policy explicit and executable first, get the decision data clean enough to learn from, and sequence any AI-assisted decisioning after the rule surface is stable rather than in place of it. The order matters more than the tooling.

Test the roadmap against the org chart

The roadmap in the deck is a statement of intent. Whether it is achievable is an organizational question, not a technical one.

I map the roadmap's critical path onto the people who would actually execute it. A plan that needs three senior engineers in the settlement domain, at a company where two people understand settlement and one of them is the CTO, is not a plan. It is a hope with dates on it.

Related: I ask what the team can safely change. Codebase health is better measured by blast radius than by lint scores. Which areas can a new engineer modify in their first month? Which areas require the one person? The ratio between those two tells you how much of the value-creation plan is actually available.

On AI, one honest note

Nearly every payments company now has an AI plan. Most of them are downstream of data the company cannot reconcile.

Agent-initiated volume is the clearest example. It does not introduce new payment requirements. It removes the human workarounds that were hiding the old ones — because an autonomous transaction cannot call support to sort out a refund, cannot assemble dispute evidence by hand, and cannot tolerate settlement that only balances after someone adjusts it.

So the AI question in diligence is not what the company plans to build. It is whether the fundamentals underneath would survive the removal of manual intervention. If they would not, the AI roadmap is a second project wearing the costume of a first one.

The question that predicts year two

If I had one question, it would be this: what does this company do that only works because a specific person is still here?

Every payments platform has an answer. The answer is not disqualifying — it is normal, and it is fixable. What matters is whether the company knows the answer, and whether the price reflects it.

The platforms that surprise their new owners are not the ones with problems. They are the ones where nobody asked.