Integration Partners Get Paid Nothing — And That's Why Integrations Rot

Short answer: in SaaS partner programs, referral partners typically earn 10–20% of first-year revenue and resellers 20–40% of ongoing revenue, while technology and integration partners usually earn nothing at all — they co-market instead. That is the cause of the thing everyone complains about and nobody explains: integrations that quietly stop working a few months after the launch post. Maintenance is unfunded, so it loses every prioritisation argument it is ever in. The fix is to make the integration itself the revenue source, and to scope the share to the revenue it actually created.

The pay table nobody looks at sideways

Open any guide to building a SaaS partner program and you will find a version of the same table. Referral partners: 10–20% of first-year revenue. Resellers: 20–40% of ongoing revenue. Integration or technology partners: no revenue share — co-marketing and co-selling instead.

Read that table again with the work in mind rather than the label. The referral partner sent an email. The reseller ran a sales process. The integration partner wrote software that lives inside another company's product, took on a support obligation to that company's customers, and accepted a dependency they now have to keep alive through every API change on both sides.

The party doing the most durable, most operationally binding work is the only one in the table with no revenue attached. It is not a rounding error in how partnerships are structured — it is the structure.

What unfunded maintenance actually does

Nothing dramatic happens on day one. The integration ships, both sides publish a post, and for a while it works. The failure is a slow one, and it runs like this.

1. Month one. Launch post, a spike of signups, a Slack channel with eight people in it. Everyone is pleased.
2. Month three. One side ships a breaking change to an endpoint. The integration half-works. A support ticket arrives at whichever product the user was looking at, which is usually not the product that broke it.
3. Month four. Fixing it is a day of engineering. On both roadmaps, that day is competing against work with a revenue number next to it. The integration has no revenue number next to it, because that was the deal. It loses. It will keep losing.
4. Month nine. The docs page is still up. The feature is still listed. It has not worked properly since March, and neither company knows, because nobody is watching a line that never had money in it.

The interesting part is that no one behaved badly. Two rational teams each declined to spend engineering time on an asset that generates no revenue for them. The incentive was missing from the beginning; the outage merely revealed it.

Why the co-marketing default persists anyway

The default is not stupid. It is the residue of a world where integrations were built between companies of very different sizes.

If you are a fifty-person SaaS integrating with a platform that has ten thousand customers, you are not negotiating a revenue share. You are grateful to be in the directory, because the directory is distribution, and distribution is the whole payment. The platform, meanwhile, has no interest in a revenue share either: your integration makes their product stickier at your expense, which is a very good trade for them.

That asymmetry is what "integration partners co-market instead" is actually describing. It was never a fair-value calculation. It was a bargaining-power outcome, written down often enough that it became a best practice.

Between two small products with roughly equal footing, the same default is simply broken. Neither side's directory is distribution. Neither side can pay the other in exposure. What is left, if nobody puts money in the deal, is two teams doing unpaid work for each other and hoping the other one keeps caring.

The obvious objection: build it yourself

Why partner at all? Features are cheap now. You can have a working version of most adjacent capabilities in a week with AI assistance.

That objection is correct, and it should be conceded completely rather than argued with. There is no good answer to "couldn't you just build that?", and there should not be — the cost of building a feature has collapsed and it is not coming back.

But it answers a question nobody asked. The reason to run an integration partnership is not that the feature is hard to build. It is that a feature you build is worth what a user will pay for it, while a capability your partner is paid to keep working comes with something you cannot build: a second company with a commercial reason to care about your customers staying. You are not buying code. You are buying an aligned counterparty.

And when the partner is larger than you, the revenue share is the only thing that will get you prioritised at all. You cannot get a bigger platform to spend engineering time on an integration with you out of goodwill. A share of revenue turns the request from a favour into a line item.

What it is not: an affiliate deal

The moment money enters an integration conversation, someone says "so it's an affiliate deal". It is worth being precise about why it isn't, because the distinction is the whole design.

Being paid per transaction is not what makes something an affiliate network. Two other things do:

• It is one-time. A bounty on a signup ends the relationship at the handoff. Neither side has any stake in what happens to that customer afterwards. A perpetual share of an account's lifetime makes both sides care whether the customer stays.
• It is one-directional. Value flows one way, from the party with the audience to the party with the product. In an integration between two products that each have users, both sides are host and partner at different moments, so it runs in both directions by construction.

There is also a simpler difference. A referral moves a lead somewhere else. An integration changes what you can sell — your users can now do something inside your product that they could not do before, and you charge for it. Those are not variations on one idea. One is a marketing arrangement; the other is a product change with a contract attached.

How to structure one that survives

Four decisions do most of the work. Get these right and the rest is negotiable.

1. Scope the share to what the integration created

The fastest way to kill a revenue-share conversation is to leave the base undefined, because the other side hears "a percentage of my whole business". Name the products or prices in scope — the add-on, the tier, the specific SKU the integration made possible — and leave everything else untouched. A tight base makes a generous percentage easy to agree to.

2. Pay on growth when there is history to protect

If the revenue in scope already existed before the partner arrived, sharing all of it is a transfer, not a partnership. Capture a baseline when the agreement starts and share only what comes in above it. If the integration lifts a €10,000 month to €13,000, the split applies to the €3,000. Both sides can defend that number in six months, which is the real test of a revenue-share structure.

3. Assign support before anything ships

Whoever's product the user is looking at takes first-line support. It is their interface and their customer, and that customer should never have to work out whose fault an error is. The partner owns the layer underneath and commits to a response time in writing. This single clause converts the month-three outage from a founder-to-founder argument into a process with an owner and a clock.

4. Give it a term and an exit

A deal that is easy to leave is much easier to enter. Put a duration on it. And note that an integration is unusually clean to unwind by construction: a capability stops answering when the partner stops serving it, a handoff stops provisioning, a placement leaves nothing behind. You do not need a divorce clause for something that ends by simply not being called.

The part that is still manual

Everything above is coordination work, and coordination is why founders skip it: finding a partner whose users are genuinely your users, agreeing a scope, papering it, then tracking and settling the money every month. That is the work Ordana automates — matching, the integration plan, the contract with identity-verified signatures, the revenue-share rules scoped to specific Stripe products, and automatic payouts on every in-scope charge, out of each member's own Stripe account.

What it does not do is write the integration. There is no generated integration code, no SDK and no revenue tag today; those are unbuilt, and the members write the integration themselves. That is worth stating plainly rather than implying otherwise, because a founder who discovers it after signing up is a founder who does not come back.

The takeaway

The received structure for integration partnerships — build it together, market it together, pay nobody — was inherited from deals between very unequal companies, where exposure was the payment. Between two small products it produces exactly what you would predict: an asset both sides own, neither side is paid for, and neither side maintains.

If you want an integration that is still working next year, put revenue in it. Not a bounty on a signup — a share of what the integration earns, scoped to what it created, for a defined term, with support ownership named in advance. That is not an affiliate deal with extra steps. It is the difference between a launch post and a business relationship.

Related reading:

• How to Find Integration Partners When You Have 300 Users — the four gates, and why account mapping can't help you yet.
• You Don't Need More Traffic. You Need More to Sell. — why expansion revenue is the cheapest revenue you can win.
• Integrate, Don't Build: Validate a Feature Without Building It — the same mechanics used as a validation engine.

See how integration revenue share works on Ordana →