Payments Are the Biggest Revenue Opportunity Most Platforms Ignore
Every platform has a payments moment — the point where money changes hands inside (or because of) the platform's workflow. Insurance premiums collected. Invoices settled. Bookings paid. Service fees charged.
Most platforms either ignore this moment (letting merchants handle payments elsewhere) or hand it to a single PSP like Stripe Connect or Adyen for Platforms.
Both approaches leave money on the table.
Ignoring payments means missing a revenue stream that typically increases per-customer value by 2-5x. Handing it to a single PSP captures some of that value — but caps your addressable market to merchants who'll accept that PSP.
The third option: embed payment infrastructure that lets you monetise transactions regardless of which PSP the merchant uses.
The Three Payment Revenue Models for Platforms
1. Transaction Revenue Share
How it works: The platform takes a percentage or fixed fee on every transaction processed through the platform. The payment layer handles the processing, and the platform earns on top.
Example: A field service platform processes $10M in annual payment volume. At a 0.5% revenue share, that's $50K in additional annual revenue — on top of the platform's SaaS subscription.
Why it works: Revenue scales with merchant success. The more transactions a merchant processes, the more the platform earns. This aligns incentives and makes payment revenue a growth multiplier, not a fixed line item.
**The lock-in risk:** If you build this on Stripe Connect, your revenue share only applies to Stripe-processed transactions. Enterprise merchants who mandate Worldpay, Adyen, or a regional acquirer process outside your revenue share entirely.
2. Payment Feature Upsell
How it works: The platform offers payment capabilities as a premium feature — either bundled into higher-tier plans or sold as add-ons.
Example: An ERP platform offers a free plan with manual invoice management. The premium plan adds payment links, recurring billing, and multi-currency support. The payment features justify a higher price point.
Why it works: Payment features increase platform stickiness. Once merchants are collecting payments through the platform, switching costs are high. This reduces churn and increases lifetime value.
The lock-in risk: If your payment features only work with one PSP, merchants with existing PSP relationships can't adopt them. You've built a premium tier that excludes your most valuable potential customers.
3. Payment Operations Revenue
How it works: The platform handles payment operations — onboarding, reconciliation, reporting, dispute management — and charges for the service, either directly or embedded in platform fees.
Example: A marketplace platform manages merchant onboarding, handles payouts across regions, and provides unified reporting across all payment methods. These operational capabilities are priced into the marketplace take rate.
Why it works: Payment operations are complex, tedious, and compliance-heavy. Merchants will pay to have someone else handle it. And platforms that control the operational layer control the merchant relationship.
The lock-in risk: If your operational tools only work with one PSP's data format and settlement process, you can't extend them to merchants using other PSPs. Your operational layer becomes PSP-specific instead of universal.
Why Single-PSP Lock-In Caps Your Revenue
The maths is straightforward.
Scenario: Your platform has 1,000 merchants. 700 are happy to use whatever PSP you offer. 300 are enterprise merchants who mandate their own PSP or need a regional acquirer.
With single-PSP architecture (Stripe Connect):
You monetise 700 merchants' payment volume
The 300 enterprise merchants either process payments outside your platform (you earn nothing) or you lose the deal entirely
Your addressable payment revenue: 70% of potential
With PSP-neutral architecture:
You monetise all 1,000 merchants' payment volume
Enterprise merchants connect their mandated PSP — transactions still flow through your platform
You earn revenue share on every transaction regardless of gateway
Your addressable payment revenue: 100% of potential
The 300 enterprise merchants are typically your highest-value customers — processing the most volume, paying the highest subscriptions. Losing their payment revenue (or losing them entirely) is the most expensive outcome.
How PSP-Neutral Payment Monetisation Works
The Architecture
Your platform integrates once with the payment layer. The payment layer connects to every PSP. Merchants process through whichever gateway they choose (or whichever is best for their geography).
Your revenue share applies to all transactions, regardless of PSP.
What This Looks Like in Practice
Onboarding: A new merchant signs up for your platform. During setup, they choose their PSP — or your platform defaults them to the best option for their region. The merchant's payment configuration happens inside your platform's white-label flow. They never interact with the payment layer directly.
Processing: Transactions flow through your platform's checkout, payment links, voice channel, or AI agent. The payment layer routes each transaction to the merchant's configured PSP. Your revenue share is calculated and settled automatically.
Expansion: An enterprise customer in Germany needs a European acquirer. You configure their regional PSP through the payment layer — no engineering work, no new integration. Their transactions flow through the same platform experience. Your revenue share applies.
Multi-channel: A merchant starts with embedded checkout. Later, their contact centre wants voice payments. Then their sales team wants payment links. Every channel runs through the same payment layer. Every transaction generates platform revenue. One integration covers all channels.
Revenue Projections: What Payment Monetisation Is Worth
These figures are illustrative based on typical platform payment volumes:
Platform Size | Annual Payment Volume | Revenue Share (0.5%) | Revenue Share (1.0%) |
|---|---|---|---|
100 merchants | $5M | $25K | $50K |
500 merchants | $50M | $250K | $500K |
1,000 merchants | $200M | $1M | $2M |
5,000 merchants | $1B | $5M | $10M |
For context: a 1,000-merchant platform charging $200/month in SaaS subscriptions generates $2.4M in subscription revenue. Adding a 0.5% payment revenue share on $200M in volume adds $1M — a 42% increase in total revenue.
Payment revenue grows with merchant success. SaaS revenue doesn't (unless you raise prices). This is why embedded payments change platform economics.
Getting Started
Step 1: Calculate Your Payment Opportunity
What's the total annual payment volume flowing through (or around) your platform?
How many merchants process payments as part of their workflow?
What percentage would use your embedded payment features if they were available?
What revenue share would be reasonable without driving merchants away?
Step 2: Evaluate Your Architecture
Do you currently lock merchants into a single PSP?
Have you lost enterprise deals because of PSP inflexibility?
Are you expanding into geographies where your current PSP has gaps?
Do you need payment channels beyond online checkout?
Step 3: Choose Your Revenue Model
Transaction revenue share: best for high-volume platforms
Feature upsell: best for platforms with tiered pricing
Operational revenue: best for platforms that manage the full merchant workflow
Most platforms use a combination
FAQ
What revenue share is typical?
Platform revenue shares on payments typically range from 0.3% to 1.5%, depending on transaction volume, average transaction value, and competitive dynamics. Higher-volume merchants often negotiate lower shares. The key is that the revenue share is additive — it sits on top of the PSP's processing fees, not instead of them.
Won't merchants object to paying more on top of their PSP fees?
Merchants are already paying PSP fees. Your revenue share is the cost of the platform's payment infrastructure — onboarding, tooling, reporting, multi-channel support, and the convenience of payments embedded in their workflow. Most merchants accept this as they would any platform fee. The ones who push back hardest are typically enterprise merchants with direct PSP relationships — which is exactly why PSP flexibility matters.
How does this work with enterprise pricing?
Enterprise deals often negotiate custom payment terms — lower revenue shares in exchange for higher subscription fees, or volume-based tiers that reduce the share as processing grows. PSP-neutral architecture gives you flexibility to structure these deals however the commercial terms require.
Can I still do this if I'm on Stripe Connect today?
Yes. The most common migration path is additive: add a payment layer alongside Stripe Connect, move new merchants to the multi-PSP setup, and gradually migrate existing merchants as contracts renew. Stripe remains as one PSP option — you're just no longer limited to it.
Related Reading
When Your SaaS Outgrows Stripe Connect — what to do when single-PSP lock-in caps your revenue
Shuttle vs Stripe Connect — the PSP-neutral vs PSP-owned comparison
Shuttle vs Adyen for Platforms — same comparison for Adyen
How to Get Payments Off Your Product Roadmap — free up engineering to build revenue-generating features instead
Shuttle vs Building In-House — why the build path costs more than it saves
How PSPs Get Distribution Into Enterprise Software — the PSP-side view of platform payments
Ready to turn payments into revenue?
See how platforms use Shuttle to monetise payments across 40+ PSPs — with embedded checkout, voice, links, and AI channels. No PSP lock-in. Revenue share on every transaction.