How SaaS Platforms Can Monetise Customer Payments: Recurring Billing, Revenue Models and Portfolio Value

How SaaS Platforms Can Monetise Customer Payments

If 1,000 businesses already use your software and those businesses collectively process £200 million a year, you potentially sit on top of a substantial payments opportunity.

The important word is potentially.

Not every customer will use an integrated payment product. Not every merchant will meet a provider's underwriting requirements. Payment economics vary significantly by card mix, business model, geography and provider structure.

But there is a strategic question that established SaaS businesses should be asking:

How much payment volume already exists within our customer portfolio — and what could that be worth to our platform?

For many software businesses, payments historically worked like this:

SaaS platform provides software → customer chooses payment provider independently → payment provider earns from every transaction.

The software platform may create the booking, subscription, order, invoice or transaction that generates the payment while participating in none of the payment economics.

Modern integrated and embedded-payment models can change that.

Depending on the arrangement, a SaaS business may be able to:

• integrate payments directly into its product;
• offer recurring payments to customers;
• streamline merchant onboarding;
• improve reconciliation;
• offer online and in-person payments;
• influence or control payment pricing;
• earn revenue share;
• retain transaction margin; or
• develop payments into a new recurring revenue stream.

The starting point, however, should not be choosing a payment provider.

It should be understanding the commercial value of the customer portfolio you already have.

For the wider platform-payment structures, see our Embedded Payments for SaaS and Platforms guide and Integrated Payments for ISVs guide.

SaaS platforms considering recurring or embedded payments need to think beyond billing alone, including tokenisation, integrations, merchant structure, onboarding and provider functionality. Our main Payment Gateways guide provides an overview of the wider gateway options available.

Key Takeaways

For an established SaaS platform, payment monetisation starts with four numbers:

number of active business customers × expected payment adoption × average customer payment volume = potential addressable payment volume

Only once that figure is understood does it make sense to assess commercial models such as:

• referral revenue;
• revenue share;
• transaction fees;
• buy-rate or wholesale arrangements;
• white-label payments; or
• more involved platform-payment structures.

Current platform-payment providers demonstrate that more than one commercial model is available.

Stripe currently supports models where qualifying platforms can earn revenue share when Stripe controls connected-account pricing, as well as structures where the platform controls payment pricing and collects fees itself. See Stripe Connect pricing.

Adyen currently promotes SaaS-platform models where platforms can white-label payments, control transaction fees and monetise payment activity. See Adyen for Platforms.

Worldpay for Platforms similarly supports configurable payment fees that can be applied at merchant, portfolio or transaction level. See Worldpay configurable fees.

The best model is not automatically the one offering the highest headline revenue share.

A SaaS platform also needs to consider customer adoption, merchant pricing, integration, customer ownership, underwriting, operations, risk and long-term portability.

Your Customer Base May Already Be a Payments Portfolio

Suppose a vertical SaaS company provides business-management software to 2,000 customers.

Those customers already accept payments, but they may use Stripe, Worldpay, PayPal, local acquirers, bank-provided merchant accounts or various other PSPs.

The SaaS company may have no involvement in those transactions.

Yet its software could already manage the workflow that causes the payment to happen.

For example:

• Booking software: booking → deposit → final payment
• Membership platform: membership → recurring subscription → payment
• Property platform: invoice → customer payment
• Hospitality software: order → bill → payment
• Professional-services software: invoice → payment request → settlement

The payment opportunity already exists.

The strategic question is whether payments should remain an external service chosen independently by each customer or become part of the software proposition itself.

Find Your New Processor

Start by Calculating the Addressable Payment Volume

Before speaking to payment providers, estimate the potential portfolio.

The basic calculation is:

Active business customers × realistic payment adoption × average monthly payment volume per participating customer = potential monthly payment volume

Then:

Potential monthly payment volume × 12 = potential annual payment volume

Example: 1,000 SaaS Customers

Assume:

• 1,000 active customers;
• 50% estimated payment adoption; and
• £30,000 average monthly payment volume.

The calculation becomes:

1,000 × 50% × £30,000 = £15 million potential monthly payment volume

Or:

£180 million potential annual payment volume

That does not mean the SaaS platform will automatically process £180 million.

Some customers may remain with existing providers. Some may not qualify. Some may have contractual commitments. Payment volume will vary.

But it gives the platform something commercially important: an estimate of the payment portfolio it could potentially bring to a provider relationship.

MAS View

A software company potentially introducing £180 million of annual payment volume should understand that before asking a provider: “What revenue share can you offer us?”

Otherwise, it is trying to negotiate the value of an asset it has not yet measured.

Don't Start With 100% Customer Adoption

This is one of the easiest ways to overstate a payments business case.

Existing customers may already have:

• negotiated processing rates;
• long-term provider contracts;
• stored payment credentials;
• recurring subscriptions;
• terminal estates;
• finance integrations; or
• preferred settlement arrangements.

Adoption should therefore be modelled in scenarios.

This gives management a more useful picture than assuming every software customer will automatically adopt the platform's payment proposition.

Then Model What the Payment Portfolio Could Be Worth

Once addressable volume is understood, the next calculation is broadly:

Addressable payment volume × potential net platform economics = indicative platform payment revenue

This is deliberately described as net platform economics rather than a guaranteed margin.

The actual amount retained by a platform can depend on:

• interchange;
• scheme fees;
• acquiring costs;
• payment method;
• customer pricing;
• provider pricing;
• transaction fees;
• international cards;
• refunds;
• chargebacks;
• platform fees;
• fraud losses;
• commercial model; and
• which party assumes which responsibilities.

Illustrative Example Only

Suppose the platform eventually processes £100 million annually.

If its final net economics were hypothetically equivalent to 0.10%, that would represent £100,000 annually.

At 0.20%, it would represent £200,000 annually.

At 0.30%, it would represent £300,000 annually.

These figures are illustrative calculations only and do not represent expected provider pricing or guaranteed payment margin.

Their purpose is to show why relatively small payment economics can become commercially significant when applied to a large customer portfolio.

Payment Monetisation Is Not One Business Model

Very different commercial arrangements are often grouped together under terms such as integrated payments, embedded payments and payment monetisation.

In practice, the economics and responsibilities can be very different.

These are broad commercial categories rather than fixed industry definitions. Different providers use different terminology.

Find Your New Processor

Revenue Share: Simple, But Potentially Less Control

In a revenue-share structure, the payment provider may retain greater responsibility for merchant pricing and the payment relationship while sharing an agreed portion of payment revenue with the platform.

Stripe currently supports this type of model through Connect, where Stripe can set and collect processing fees from connected accounts and qualifying platforms can earn revenue share. See Stripe Connect pricing.

Potential advantages include:

• relatively simple commercial structure;
• less payment-pricing management;
• provider-controlled merchant pricing;
• less operational involvement; and
• recurring income linked to customer payment activity.

The platform may, however, have less control over merchant pricing, margin and the wider commercial proposition.

For some SaaS businesses, that may be entirely appropriate.

What Is a Buy-Rate or Wholesale Payment Model?

A buy-rate or wholesale-style model can give the platform greater influence over payment economics.

Broadly, the provider agrees underlying payment terms with the platform. Where the arrangement permits it, the platform can then determine how the payment service is commercially offered to customers.

Conceptually:

Customer payment price − underlying payment economics = potential platform margin

The actual calculation can be considerably more complicated and may include interchange, scheme fees, acquiring margin, gateway charges, international-card costs, cross-border fees, transaction charges, refunds and chargebacks.

Stripe currently allows qualifying platforms that take responsibility for pricing to set payment pricing for connected accounts and collect payment fees. See Stripe Connect pricing.

Adyen states that SaaS platforms using its platform-payment proposition can control transaction fees and monetise payments. See Adyen for Platforms.

Worldpay for Platforms provides configurable fee functionality that can be applied at merchant, portfolio or transaction level. See Worldpay configurable fees.

These are examples of current provider capabilities, not provider recommendations.

More Pricing Control Also Means More Pricing Responsibility

This is the part payment-monetisation articles often underplay.

Suppose your platform receives attractive underlying economics and then sets payment pricing for customers.

You are no longer simply receiving referral revenue.

You need to understand whether merchant pricing remains competitive as:

• interchange changes;
• scheme fees change;
• card mix changes;
• international transactions increase;
• customers grow;
• transaction values change; and
• competitors alter their own payment propositions.

MAS View

Greater payment margin is not free money.

The more control a platform wants over pricing, the more payment expertise it needs internally or from specialist partners.

Recurring Payments Can Make SaaS a Particularly Natural Fit

Recurring payments remain one of the strongest use cases for SaaS platforms.

Consider software serving:

• gyms;
• membership organisations;
• professional associations;
• education providers;
• clubs;
• subscription businesses;
• childcare providers;
• property businesses; or
• service companies.

The software may already know who the customer is, what they should pay, when they should pay, whether the payment succeeded and what should happen if it fails.

Embedding recurring payments means billing and operational status can become more closely connected.

For example:

membership created → payment method established → monthly payment collected → payment status returned to platform → membership remains active

If payment fails:

failed payment → retry or dunning process → customer updates card → membership status updated

For a deeper look at recurring-payment requirements, see our Subscription Payment Processing guide.

Recurring Payments Are Only One Part of the Opportunity

A SaaS platform may initially introduce payments because customers need recurring billing.

But the eventual opportunity could include:

• one-off online payments;
• payment links;
• invoices;
• in-person payments;
• deposits;
• card-on-file payments;
• refunds;
• Apple Pay and Google Pay;
• international transactions; and
• alternative payment methods.

The payment strategy should therefore consider what customers may need in three years, rather than building exclusively around today's recurring-payment requirement.

Payment Adoption Matters More Than the Headline Revenue Share

Imagine two payment providers.

Provider A

Offers a higher potential commercial return, but customers experience complicated onboarding, slow underwriting, poor reporting and limited integration.

Provider B

Offers slightly lower economics, but customers onboard quickly, the payment experience integrates properly, reconciliation is strong and adoption is considerably higher.

Provider B could produce more actual platform revenue.

A useful platform equation is therefore:

eligible merchants × merchant adoption × merchant payment volume × net platform economics = realised payment opportunity

Headline margin is only one variable.

Merchant Onboarding Is a Revenue Issue

A SaaS business may have thousands of customers, but each business accepting payments may still need to satisfy the underlying provider's merchant verification and underwriting requirements.

Depending on the model, this can involve:

• company information;
• ownership details;
• directors;
• bank accounts;
• identity verification;
• business model;
• expected processing volume;
• website information; and
• sector.

Adyen's current platform product includes embedded user onboarding and verification. See Adyen for Platforms.

The practical question for a SaaS business is:

How much of this process can happen naturally inside our existing software journey?

Existing Customers and New Customers Need Different Payment Strategies

For a SaaS platform launching integrated payments, new customers are usually easier.

A new customer can potentially experience:

create software account → configure business → activate payments → start trading

Payments become part of onboarding.

Existing customers are different.

They may already have:

• a PSP;
• negotiated card rates;
• stored credentials;
• subscriptions;
• terminals;
• bank settlement;
• integrations; and
• contracts.

For existing customers, the platform needs a migration proposition, not just a payment feature.

Where stored credentials or recurring payments are involved, see our guide to moving stored cards, tokens and recurring payments between providers.

Don't Assume Customers Will Move Just Because Payments Are Embedded

A merchant may reasonably ask:

“Our current PSP works. Why should we change it?”

The platform needs an answer stronger than:

“Because payments are now built into our software.”

The payment product should create tangible value.

This might be:

• bookings automatically reconciling with payments;
• subscription status updating automatically;
• payments and software reporting sitting together;
• merchants needing fewer systems;
• simpler onboarding;
• competitive payment pricing; or
• new functionality available only through the integrated proposition.

Payments should strengthen the core software proposition rather than simply create another revenue line for the SaaS business.

Customer Pricing Needs to Be Sustainable

There is a temptation to maximise payment margin.

That can be counterproductive.

If merchants can easily obtain substantially better payment pricing elsewhere, adoption may suffer.

The platform should balance:

platform economics

with:

customer value

MAS View

The best payment pricing strategy is not necessarily:

“What is the maximum margin we can make?”

It is:

“What pricing supports adoption, retention and sustainable payment revenue?”

Who Owns the Merchant Relationship?

This question becomes increasingly important as the portfolio grows.

Suppose your SaaS platform successfully moves 1,500 customers onto an integrated-payment proposition and those merchants generate £300 million of annual payment volume.

Three years later, the platform wants to change payment provider.

What happens?

Ask before signing:

• Who contracts with each merchant?
• Who owns the commercial payment relationship?
• Whose brand does the merchant see?
• Who controls pricing?
• Who supports the merchant?
• Who stores payment credentials?
• Can those credentials move?
• Can the platform migrate the portfolio?
• Does each merchant need to reapply?
• What happens if the partnership terminates?
• What data can the platform retain?

These questions may feel less important at launch. They become strategically significant once the payment portfolio has scale.

Payment Portability Should Be Part of Provider Selection

The software business should consider the future:

What happens if this provider is no longer right in five years?

Relevant questions include:

• Can payment tokens be migrated?
• Can merchants move?
• Can another PSP be integrated?
• Does the platform own its internal payment and customer IDs?
• Does billing logic sit inside the PSP?
• Can merchant and payment data be exported?
• Can multiple acquirers eventually be supported?

Our guide to changing payment gateways and moving stored cards, tokens and recurring payments explains why these decisions matter.

For platforms considering future provider flexibility, see our Acquirer-Agnostic Payment Gateways guide.

Should SaaS Platforms White-Label Payments?

Potentially.

But white labelling should not automatically be assumed to be the best model.

A white-label structure can allow more of the payment experience to sit under the software company's brand.

Possible benefits include:

• stronger product consistency;
• greater control over customer experience;
• less visible fragmentation;
• potentially greater commercial ownership; and
• payments becoming more closely associated with the SaaS brand.

But the platform should also establish:

• who provides the regulated payment service;
• who contracts with the merchant;
• who handles support;
• who carries risk;
• who handles disputes;
• who performs underwriting;
• who is visible on statements and agreements; and
• what responsibilities the SaaS business itself assumes.

For more detail, see our White-Label Merchant Processing guide.

Find Your New Processor

Does a SaaS Platform Need to Become a PayFac?

No — not automatically.

Modern platform-payment structures can allow software businesses to integrate payments while the underlying provider retains significant responsibility for:

• merchant onboarding;
• verification;
• acquiring;
• processing;
• settlement;
• risk; and
• compliance.

Different structures place different responsibilities on the software company.

The strategic question is therefore:

How much control do we actually want?

rather than:

How do we become a PayFac?

For the broader distinction between platform models, see our Embedded Payments for SaaS and Platforms guide.

Are SaaS Platforms Regulated When They Offer Payments?

Potentially, depending on what the platform actually does.

The fact that payment technology is embedded into software does not by itself determine the platform's regulatory status.

The underlying funds flow and activities matter.

The Financial Conduct Authority states that businesses may be providing payment services where, for example, they bring sellers and customers together and receive customer money before passing it to the seller.

The FCA specifically advises relevant marketplace and booking-style businesses to assess their payment flows and seek specialist advice where uncertain.

See the FCA guidance on considering whether your business provides payment services.

A SaaS business should establish:

• who receives the customer's money;
• whose account holds it;
• who transfers it;
• who provides acquiring;
• who pays the merchant;
• who performs regulated payment functions; and
• what contractual role the platform itself has.

Merchant Advice Service does not provide legal or regulatory advice.

Don't Assume “The Provider Handles Compliance” Answers Everything

A payment provider may undertake substantial KYC, KYB, underwriting, transaction monitoring, fraud management and regulated payment activity.

That can materially reduce what the SaaS platform needs to build.

But it does not mean the software company has no responsibilities.

The precise position depends on product design, contractual structure, funds flow, merchant relationship, geography and the activities actually performed.

This should be resolved during product design, not after payments have launched.

Can Payments Become Material to the Value of the SaaS Business?

Potentially, but this needs careful wording.

Payments can introduce a new form of recurring revenue alongside software subscription revenue.

If the platform successfully embeds payments, the business may develop:

• software subscription revenue;
• payment-related revenue;
• stronger product adoption;
• deeper customer integration; and
• additional transaction data.

That can be strategically important.

However, there is no universal formula saying that adding payments increases a SaaS company's valuation by a particular amount.

Business valuation depends on many factors including revenue quality, margins, growth, customer concentration, retention, contractual arrangements, dependency on third parties, risk and durability of the payment revenue stream.

A board considering payment monetisation should therefore ask:

Could payments create a material, recurring and defensible revenue stream alongside our core software business?

If the answer is yes, the payment-provider agreement itself becomes strategically important.

The SaaS Platform Should Build a Payment P&L

Once payments become a meaningful product line, they should not disappear inside general SaaS revenue.

Management should be able to understand:

• payment volume;
• active payment merchants;
• merchant adoption;
• average payment volume;
• payment revenue;
• underlying payment costs;
• net payment contribution;
• onboarding rate;
• merchant churn;
• authorisation performance; and
• support and operational cost.

Regardless of provider, the SaaS company should understand its own payment P&L.

Five Numbers the Board Should Know

1. Active Customers

How many businesses actually use the software today?

2. Addressable Payment Volume

What do those customers collectively process?

3. Realistic Adoption

What percentage could genuinely move to the platform's payment proposition?

4. Net Platform Economics

What could the platform reasonably earn after underlying payment costs?

5. Operational Cost

What will it cost the organisation to operate the payment proposition properly?

Only then can management judge whether payments are a useful feature or a meaningful new business line.

What Should You Know Before Approaching Payment Providers?

Customer Portfolio

• active customer count;
• customer sectors;
• customer countries;
• average customer size;
• retention;
• growth rate; and
• current payment providers.

Payment Opportunity

• average monthly payment volume;
• total addressable volume;
• average transaction value;
• online vs in-person;
• recurring vs one-off;
• card mix;
• currencies; and
• important payment methods.

Product Requirements

• merchant onboarding;
• embedded checkout;
• recurring payments;
• terminals;
• reporting;
• tokenisation;
• refunds;
• payment links;
• international expansion; and
• customer portal requirements.

Commercial Objectives

• revenue share;
• payment margin;
• customer retention;
• better UX;
• product differentiation;
• white labelling;
• international expansion; or
• a combination.

Strategic Requirements

• customer ownership;
• token portability;
• contract length;
• future PSP flexibility;
• support expectations;
• underwriting responsibility; and
• regulatory structure.

The Provider Conversation Changes Once You Know the Numbers

Conversation A

“We're a SaaS platform and would like to add payments. What revenue share can you offer?”

Conversation B

“We have 1,400 active UK and European business customers. Approximately 900 currently accept card payments. Based on a sample of our portfolio, we estimate addressable annual payment volume of £240 million. We expect initial payment adoption of 30–40%, increasing as existing customer contracts renew. We need recurring payments, tokenisation and merchant onboarding inside our platform, and we want to compare revenue-share and platform-pricing structures.”

Conversation B is materially stronger.

MAS View

Providers should be competing for a defined payment opportunity — not educating the platform about an opportunity it has not yet measured.

How Merchant Advice Service Approaches SaaS Payment Monetisation

Merchant Advice Service looks at the commercial opportunity before focusing on individual provider brands.

For an established SaaS or software platform, that means understanding:

customer portfolio → addressable payment volume → expected adoption → payment requirements → preferred commercial model → provider structure

The objective is to determine what the platform is actually trying to build.

That might be:

• simple integrated recurring payments;
• a revenue-share model;
• a broader embedded-payments proposition;
• white-labelled payments;
• greater pricing control; or
• a more sophisticated payment business.

Only then does provider selection become meaningful.

MAS can then identify and introduce relevant payment-provider routes for further commercial and technical evaluation.

The underlying processing relationship remains between the relevant businesses and payment provider.

For more on the approach, see How Merchant Advice Service Works and How MAS Researches and Compares Payment Providers.

Find Your New Processor

Sources & Further Reading

Stripe Connect — Platform Pricing and Payment Monetisation

Stripe currently supports provider-controlled pricing with potential qualifying revenue share and platform-controlled pricing where platforms can collect payment fees.

Stripe Connect pricing

Adyen for Platforms — Embedded Payments

Adyen currently allows SaaS platforms to white-label payments, control transaction fees and monetise payments while supporting merchant onboarding and payment acceptance.

Adyen embedded payments for platforms

Worldpay for Platforms — Configurable Fees

Worldpay currently allows software platforms to create and configure payment fees at merchant, portfolio or transaction level.

Worldpay configurable payment fees

Financial Conduct Authority — Consider if You Provide Payment Services

FCA guidance explains circumstances in which platforms, marketplaces and booking businesses may need to consider whether their activities amount to regulated payment services.

FCA payment-services guidance

Related Merchant Advice Service Guidance

• Payments Strategy Library
• Embedded Payments for SaaS and Platforms
• Integrated Payments for ISVs
• White-Label Merchant Processing for SaaS and Platforms
• Subscription Payment Processing
• Split Payment Gateways for Marketplaces and Platforms
• Changing Payment Gateway: Stored Cards, Tokens and Recurring Payments
• Acquirer-Agnostic Payment Gateways

Editorial and Commercial Disclosure

Merchant Advice Service is an independent payments information, comparison and provider-matching service.

MAS may receive commission or a referral fee from some payment providers where a business chooses to proceed following an introduction. This does not determine the factual information, analysis or provider capabilities included in this guide.

Providers have not paid for inclusion in this article unless explicitly stated.

Payment providers named within this guide are examples used to illustrate current commercial and technical models. They do not represent a complete whole-of-market list or ranking.

Revenue-share, buy-rate, wholesale, embedded and white-label payment models vary considerably between providers. Availability and commercial terms may depend on payment volume, customer sectors, geography, card mix, underwriting requirements, platform responsibilities and other factors.

Worked payment-volume and revenue calculations within this guide are illustrative examples only and do not represent expected or guaranteed provider pricing, margins or platform revenue.

An integrated or embedded-payment model does not guarantee that every customer within a SaaS portfolio will qualify for processing. Merchant eligibility and provider underwriting criteria vary.

Embedding payments into software does not by itself determine a platform's regulatory status. Businesses should establish the responsibilities of each party and obtain specialist legal or regulatory advice where appropriate.

Merchant Advice Service does not make payment-provider underwriting decisions or guarantee merchant-account acceptance or particular commercial terms.

Provider information last checked: 25 August 2026

This guide provides general payment information and should not be treated as legal, regulatory, financial, tax or investment advice.