Private equity firms are very good at asking companies uncomfortable questions.
Why are margins down?
Why do we have three vendors doing basically the same thing?
Why hasn't this contract been renegotiated?
Why are two portfolio companies building the same capability independently?
Where is the operating leverage?
Who owns this number?
Then payments walks into the room wearing a processor statement and somehow gets treated like a utility bill.
That is a mistake.
If you own multiple companies that accept, facilitate, monetize, route, or otherwise depend on payments, there is a good chance your portfolio has a payments business whether you've chosen to manage it like one or not.
The uncomfortable part is that your processors may understand pieces of that business better than you do.
They know the volume.
They know the pricing.
They know the payment methods.
They know the authorization performance.
They know the integration model.
They know the contract.
They know how hard it would be for the company to leave.
They know which products depend on their tokens, APIs, reporting, settlement files, and fraud tools.
Meanwhile, the sponsor may be looking at each portfolio company separately and never asking what the combined picture looks like.
That is where leverage, duplication, risk, and revenue opportunities can disappear in plain sight.
How much payment volume does the portfolio process?
Not one company.
The portfolio.
Add it up.
Card volume.
ACH volume.
International volume.
Card-present volume.
Card-not-present volume.
Marketplace or PayFac volume.
Embedded payments volume.
Whatever matters for the businesses you own.
It sounds obvious.
It often isn't done.
Company A may process $80 million annually through one provider.
Company B may process $250 million through another.
Company C may process $600 million across multiple gateways and acquiring relationships.
Company D may be a SaaS platform with thousands of merchants and a payments program that has become a meaningful revenue line.
Individually, each company has a processor relationship.
Collectively, the portfolio may have serious buying power.
If nobody has assembled that picture, the negotiating leverage exists mathematically but not operationally.
Processors are not doing anything wrong by understanding their customers.
They should.
They know how much volume flows through them. They know the merchant mix. They know transaction counts, average tickets, payment methods, geography, authorization rates, disputes, fraud patterns, and the commercial terms attached to the relationship.
They also know the operational dependencies.
Is tokenization locked into the platform?
Are recurring credentials portable?
Does the company depend on proprietary reporting?
Are settlement and reconciliation workflows built around processor-specific files?
Is fraud tooling bundled into the relationship?
Would changing providers require a six-month engineering project?
Is the current contract nearing renewal?
Is there a minimum commitment?
Is there an auto-renewal provision everyone forgot about?
The processor understands the account because it manages the account every day.
The sponsor may only see "payment processing" as a line item buried inside cost of revenue.
That difference in visibility matters.
One reason payments gets ignored at the portfolio level is that the analysis often stops too early.
Someone asks, "What are we paying?"
The answer is a processor markup or a blended rate.
Great.
That is not the whole answer.
Depending on the business, the actual payments economics can include processor markup, gateway fees, tokenization, account updater, fraud tooling, network fees, cross-border costs, chargebacks, retrievals, reporting, minimums, implementation costs, payment orchestration, alternative payment methods, operational headcount, and the revenue impact of failed authorization.
A company can have a competitive-looking processor rate and still have an expensive payment stack.
Another company can pay more on paper and generate significantly better economics because its authorization performance, fraud controls, routing, and operational model are stronger.
Portfolio analysis needs to compare the whole system, not just basis points.
Otherwise you risk optimizing the number that was easiest to put in a spreadsheet.
Once a private equity team realizes five portfolio companies use six processors, four gateways, three fraud tools, and a small village of payment-related vendors, the natural instinct is consolidation.
Sometimes that is exactly the right answer.
Sometimes it is not.
Payments infrastructure is connected to product architecture, geography, merchant type, risk model, payment methods, customer experience, reconciliation, compliance scope, and go-to-market strategy.
Two companies can look similar on a portfolio map and still have very different payment requirements.
Forcing every company onto one processor because someone discovered a volume discount can create a very expensive lesson in false economies.
The goal should not be "one vendor everywhere."
The goal should be intentionality.
Where does standardization create leverage?
Where does it reduce duplicated cost?
Where can shared vendor negotiations improve commercial terms without changing infrastructure?
Where can companies share knowledge, benchmarks, or tooling?
Where does consolidation reduce risk?
And where would changing the stack create more disruption than value?
That is a portfolio strategy.
"Everybody move to Processor X" is just a group project with a sales rep.
Portfolio companies often negotiate payment agreements at very different stages of maturity.
One agreement may have been signed when the company was tiny.
Another may have been negotiated during a rushed launch.
Another may have been inherited through an acquisition.
Another may have pricing that was competitive four years ago but hasn't been benchmarked since.
Another may have excellent economics because somebody on the management team actually knew what to ask for.
Put those contracts next to each other.
Look at pricing.
Look at terms.
Look at minimums.
Look at termination rights.
Look at renewal language.
Look at data access.
Look at token portability.
Look at service commitments.
Look at reserve provisions where applicable.
Look at implementation obligations.
Look at what is bundled and what is billed separately.
You may discover that the portfolio is paying five different prices for very similar services.
You may also discover that the cheapest contract isn't the best contract.
There is another issue that tends to get overlooked: payments data.
Portfolio companies generate enormous amounts of information about customer behavior, conversion, payment methods, authorization, declines, fraud, disputes, settlement, refunds, recurring billing, and revenue quality.
How much of that data is usable?
How much is trapped in processor portals?
How much is defined differently by each company?
Can you compare authorization performance across the portfolio?
Can you identify which businesses are paying the most for similar transaction profiles?
Can you see where fraud tooling is rejecting good customers?
Can you quantify the cost of failed payments?
Can you identify portfolio companies with unusually high chargebacks or network fees?
Can you distinguish processor cost from payment program profitability?
If the answer is no, the processors may have a clearer operational view of each relationship than the sponsor has of the portfolio.
That should bother you at least a little.
Cost reduction is only half the conversation.
Some companies should not merely be optimizing what they pay for payments.
They should be asking whether payments can become part of what they sell.
SaaS platforms, vertical software companies, marketplaces, and other businesses that sit between merchants and payment providers may have an opportunity to monetize payment volume.
That does not mean adding a random markup and calling it embedded payments.
A real monetization strategy requires understanding volume, merchant mix, risk, pricing, product fit, support requirements, compliance obligations, sponsor relationships, economics, and the operational burden that comes with becoming more involved in the money flow.
But across a private equity portfolio, the opportunity can become much more interesting.
One company may already monetize payments successfully.
Another may have similar customers but no payments revenue.
Another may have built infrastructure that could inform a sister company's strategy.
Another may be sending substantial economics to a provider because nobody has ever challenged the commercial model.
That is not just procurement.
That can affect gross margin, recurring revenue, customer retention, product stickiness, and ultimately enterprise value.
This distinction is important enough to repeat.
Portfolio leverage does not require every company to run the same technology.
You can negotiate using aggregate volume without forcing every company into the same architecture.
You can benchmark commercial terms across companies without moving a single transaction.
You can identify common vendors and negotiate enterprise relationships where appropriate.
You can create shared standards for processor selection, contract review, payments data, fraud tooling, and reporting.
You can share lessons learned across portfolio companies.
You can identify which companies genuinely benefit from common infrastructure and which should remain independent.
The mature answer is rarely "centralize everything" or "leave everything alone."
It is usually a much less dramatic combination of standardization, leverage, exceptions, and informed decisions.
You do not need a 400-slide transformation deck.
You need answers.
How much volume does the portfolio process?
Which providers touch it?
What does each company actually pay?
How do commercial terms compare?
Which contracts create unnecessary lock-in?
Where is infrastructure duplicated?
Where are there meaningful operational dependencies?
Which payment vendors appear across multiple companies?
Where can aggregate volume improve pricing or contract terms?
Which companies have payments revenue today?
Which companies could potentially monetize payments tomorrow?
Where are authorization, fraud, dispute, or reconciliation problems quietly destroying value?
Where is payment data trapped or inconsistent?
Which companies have resilient payment architecture, and which have a single provider holding the entire checkout experience together with hope and an API key?
Once you can answer those questions, you can make decisions.
Before that, you mostly have anecdotes.
Maybe the analysis shows that every portfolio company should keep its current processor.
Fine.
Maybe the pricing is competitive.
Maybe the infrastructure is appropriate.
Maybe consolidation would create unnecessary disruption.
Maybe the payments programs are already well run.
That is a perfectly good outcome.
The point is not to manufacture a payments project where one does not exist.
The point is to know.
Because if you have significant payment volume across a portfolio and nobody has looked at it collectively, you are making an assumption that there is no leverage, no duplication, no hidden cost, no contract risk, no infrastructure risk, and no monetization opportunity.
That is a lot of assumptions hiding behind one line item.
Your processors know their businesses with your portfolio companies.
You should know the payments business across your portfolio.
Private equity is built around understanding assets well enough to improve them.
Payments should not be the exception.
Add up the volume.
Map the processors, gateways, fraud tools, sponsor relationships, and other meaningful dependencies.
Compare the contracts.
Normalize the economics.
Understand the data.
Find the duplication.
Identify the leverage.
Look for monetization opportunities.
Then decide what should stay independent, what should be standardized, and what should change.
If your portfolio companies move a meaningful amount of money, payments are not just a vendor category.
They are part of the asset.
And if the processors understand that asset better than the owner does, it may be time for a proper diagnosis.