Nov 11th, 2026

Your Payments Revenue Share Looks Great. Have You Read the Definition of Revenue?

TL;DR

A bigger revenue-share percentage does not guarantee better embedded payments economics. ISVs and fintechs need to understand permitted deductions, pricing control, reporting, audit rights, and exit terms before comparing offers.

Your software company just received two proposals to monetize payments flowing through its platform. Processor A offers 50% of the revenue. Processor B offers 70%. Someone has already updated the forecast, and the board presentation suddenly looks a lot more exciting.

There's just one problem. Nobody has asked the most important question: 70% of what?

Because somewhere in the agreement is a definition of revenue, and that definition can matter more than the percentage on the cover page. A generous share of a narrowly defined number can produce less money than a smaller share of a broader, more transparent one. And if you can't independently verify the calculation, you may not even know the difference.

The Percentage Is the Headline. The Definition Is the Business.

Embedded payments has become a compelling growth opportunity for ISVs, SaaS platforms, marketplaces, and fintechs. Once software becomes central to a merchant's operations, integrating payments can improve the customer experience and create a new recurring revenue stream. The opportunity is real. So is the temptation to compare proposals by the largest number in the revenue-share column.

But the economics depend on what each provider means by revenue. One agreement may start with merchant processing fees and subtract interchange, network assessments, processor costs, and other permitted expenses. Another may define the shareable amount differently, with additional deductions for services, credits, losses, or adjustments. A third may offer attractive economics for one segment of transactions but less favorable treatment for another.

None of these structures is automatically improper. Providers incur real costs, and there are legitimate reasons to define net revenue carefully. The problem is when a software company treats two percentages as comparable without first making the underlying calculations comparable.

Let's Do Some Math Before We Celebrate

Imagine a platform whose merchants generate $1 million in gross processing-related fees during a measurement period. These are illustrative numbers, not a typical pricing model or a forecast.

Under Proposal A, the contract permits $600,000 of deductions, leaving $400,000 in shareable net revenue. At a 50% share, the platform receives $200,000. Under Proposal B, a different cost definition permits $750,000 of deductions, leaving $250,000. At a 70% share, the platform receives $175,000.

The offer with the bigger percentage pays $25,000 less. The point isn't that a 70% deal is bad or that a 50% deal is good. It's that the percentage is mathematically meaningless until you know the base.

And that example is still too simple. Real portfolios contain different merchant categories, transaction sizes, card types, channels, refund patterns, and risk profiles. The mix changes over time. If the agreement allows the calculation to change as costs or pricing structures change, your projected share can move even when transaction volume grows.

Follow the Money Through the Waterfall

A useful revenue-share review starts with a transaction and follows the economics all the way to the payment you receive. What does the merchant pay? Which fees are collected by the processor or its affiliates? Which costs are passed through? Which costs are allocated? Which amounts are excluded from the pool entirely?

Interchange and network assessments are familiar categories, but they're not the end of the discussion. Agreements may address gateway fees, authorization charges, fraud tools, chargeback services, cross-border costs, account updater, tokenization, reporting, compliance-related charges, and other ancillary services. Some items may be billed to merchants separately, some may be bundled, and some may be deducted before revenue sharing.

The labels aren't enough. A fee called a 'network cost' may be a genuine pass-through, while another item might include provider markup. An expense may be assessed per transaction, per merchant, or as an allocation across a portfolio. You need to know which charges are actual third-party costs, which are internally determined, and whether the agreement permits markups or new categories without your approval.

Then ask about credits, refunds, disputes, negative balances, reserves, and losses. Are these treated as operating costs, timing adjustments, or reductions in shareable revenue? Can losses from one merchant reduce revenue earned from others? Is the calculation done at the merchant level, portfolio level, or across multiple products? Those distinctions can materially affect the payout.

Who Controls the Price Controls a Lot More Than You Think

Suppose the processor controls merchant pricing, discounting, fee waivers, and the introduction of new services. Your platform may technically receive 70% of net revenue, but the processor may have substantial influence over how much net revenue exists.

That can create misaligned incentives. A pricing concession that helps win a merchant may reduce your share. A new fee charged outside the revenue-share definition may increase the merchant's total cost without increasing your revenue. A change in how costs are allocated may affect your economics without changing the headline percentage at all.

The solution isn't necessarily to demand unilateral pricing control. Pricing decisions involve sales strategy, risk, competition, and operational realities. But the contract should make decision rights explicit: who can set or change merchant prices, what requires consent, what gets disclosed, and how exceptions are handled. If your business plan depends on payments revenue, you should know who can change the assumptions underneath it.

Reporting Isn't a Courtesy. It's How You Verify the Deal.

A monthly payment accompanied by a summary spreadsheet isn't sufficient if you can't reconcile it to the underlying merchant activity. At a minimum, you should understand what data will be available, how often it arrives, and whether it supports the calculation defined in the contract.

Can you see transaction volume, merchant fees, interchange and network costs, other deductions, adjustments, and the resulting share by merchant and period? Can you distinguish a true cost increase from a pricing change? Can you trace corrections and retroactive adjustments? Do you have an audit or review right, and is it practical enough to use?

Reporting becomes even more important during acquisitions. A buyer may value an ISV partly on embedded payments revenue, only to discover that the underlying economics depend on opaque calculations or special terms that don't transfer cleanly. A revenue stream that's difficult to validate is also difficult to underwrite with confidence.

Watch the Contract After the Honeymoon

Revenue-share agreements don't operate in a vacuum. They sit alongside processing agreements, merchant terms, service schedules, and sometimes sponsor-bank or program arrangements. The economics may also depend on minimum commitments, exclusivity, portfolio definitions, implementation milestones, or volume thresholds.

Pay attention to amendment rights. Can the provider introduce new deductions? Can it change schedules of fees or reclassify revenue? What notice is required? What happens to existing merchants if the agreement ends? Are there continuing residual payments, and under what conditions? If you sell the company, can the arrangement be assigned, or does a change of control trigger renegotiation?

These questions aren't theoretical for an ISV planning a sale or a private equity firm evaluating multiple portfolio companies. The contract that looked harmless at launch can become a major constraint when you're trying to consolidate vendors, renegotiate pricing, or build a more sophisticated payments strategy.

Five Questions Worth Asking Before You Sign

First, ask for a worked example using realistic merchant and transaction data, not just a percentage and a projected annual volume. Second, request an itemized definition of every permitted deduction and whether costs can include markup or allocation. Third, clarify who controls merchant pricing, discounts, and fee changes. Fourth, confirm the reporting and audit rights needed to independently reproduce your payout. Fifth, test the exit, acquisition, and amendment provisions before they become urgent.

Ideally, compare competing offers using the same transaction assumptions, merchant mix, and time horizon. Model what happens when volumes grow, the mix shifts, costs rise, or a meaningful merchant segment leaves. That exercise will tell you far more than comparing 50% and 70% in adjacent spreadsheet cells.

The Real Opportunity Is Bigger Than a Percentage

Embedded payments can create tremendous value. It can make software stickier, simplify merchant operations, and generate recurring revenue that grows with the businesses using your platform. But the opportunity deserves the same diligence you'd apply to any other material revenue stream.

At Payments Therapist, we help software companies, fintechs, and investors evaluate payment economics, commercial agreements, provider options, and the operational realities behind the projections. The goal isn't to negotiate the biggest-looking number. It's to build an arrangement you can understand, measure, and improve.

So the next time a processor offers you 70% of the revenue, don't reach for the champagne just yet. Reach for the definition of revenue. That's where the deal actually lives.