Embedded Payments: Adopting Seamless Payment Solutions

Embedded Payments for SaaS & Platforms: Revenue, Integration and Commercial Models

For an established software or platform business, embedded payments can be much more than another product feature.

They can become a new commercial revenue stream.

A SaaS provider, booking platform, hospitality technology business, membership platform or vertical software company may already have hundreds or thousands of customers accepting payments outside its software.

Bringing those payments into the platform can potentially improve the customer experience, strengthen the software proposition and allow the platform to participate commercially in payment volume already being generated by its customer base.

But the important question isn't simply:

“How do we add embedded payments?”

It is:

“What commercial and payment structure should sit behind them?”

That requires decisions around pricing, merchant onboarding, contracts, integrations, regulation, risk, customer ownership and the level of control the platform actually wants.

This guide is primarily for established SaaS companies, ISVs, booking platforms, marketplaces and vertical software businesses with an existing portfolio of business customers that accept payments.

If you're considering payments as part of a wider business strategy, explore the Merchant Advice Service Payments Strategy Library.

Quick Summary: Embedded Payments

Embedded payments allow payment functionality to sit directly inside software or a platform, rather than requiring each customer to independently source and connect a separate payment provider.

For an established SaaS or platform business, the opportunity can be both technical and commercial.

Depending on the provider and commercial model, a platform may be able to:

• integrate payment acceptance into its software;

• offer a branded or white-label payment experience;

• simplify customer onboarding;

• support online, recurring or in-person payments;

• set or influence the price customers pay for payment processing;

• negotiate underlying payment economics;

• earn revenue share or retain payment margin;

• integrate reporting and reconciliation;

• support different payment methods and countries; and

• make payments part of the wider value of its software proposition.

Embedded payments do not automatically require a software company to become a traditional Payment Facilitator (PayFac).

Different provider models place different levels of responsibility on the software platform and underlying payment provider.

For many businesses, that distinction is critical.

The aim should not necessarily be to gain the maximum possible control.

It should be to find the right balance between commercial value, customer experience, technology, flexibility, risk and operational responsibility.

Have an existing portfolio of business customers accepting payments elsewhere?

Find Your New Processor

What Are Embedded Payments?

Embedded payments integrate payment functionality into software customers already use to run their business.

Consider a booking platform serving 1,000 hospitality businesses.

Without embedded payments, each customer may need to:

1. find its own payment processor;

2. apply independently;

3. configure a gateway;

4. connect that provider to the booking system; and

5. manage payments partly outside the core software platform.

With embedded payments, payment functionality can instead form part of the platform proposition.

The underlying payment and acquiring services are still supplied according to the structure agreed with the relevant payment provider, but onboarding, checkout, reporting and other payment functions can potentially sit much more naturally within the software.

For the platform, this creates an important commercial question:

If our customers are already processing significant payment volume through businesses using our software, should we participate commercially in that volume?

Which Businesses Are Best Suited to Embedded Payments?

Embedded payments can be particularly relevant where a software business has an established commercial customer base with an ongoing need to accept payments.

Examples include:

• SaaS platforms;

• booking and reservation software;

• hospitality technology;

• membership platforms;

• marketplaces;

• vertical software providers;

• property-management software;

• fitness and leisure platforms;

• appointment and scheduling systems;

• education software;

• professional-services platforms;

• ecommerce technology; and

• software designed for specialist industries.

The commercial opportunity becomes particularly interesting where:

• customers already process meaningful payment volumes;

• payments naturally form part of the software workflow;

• customers currently arrange payment processing separately;

• customer retention is strong;

• payments can be offered during new-customer onboarding;

• an existing portfolio could potentially migrate;

• the software platform has a large addressable payment volume; and

• the business wants to diversify revenue beyond software subscriptions.

This is much more than adding a payment button.

The strategic opportunity is to make payments part of the commercial ecosystem surrounding the software.

How Do SaaS Platforms Make Money From Embedded Payments?

There is no single embedded-payments commercial model.

Platforms can earn payment revenue in different ways depending on the provider, contractual structure, responsibilities and level of pricing control.

Some current platform-payment propositions publicly support revenue sharing, configurable fees, application fees, platform-set pricing or wholesale/buy-rate structures.

That is why commercial structure should be considered before choosing a provider based on its API alone.

Embedded Payments Commercial Models at a Glance

Important: these are broad commercial models rather than universal industry definitions. Provider structures vary significantly, and the contractual, regulatory, underwriting and risk responsibilities must be understood in each case.

What Is a Referral or Revenue-Share Model?

At the simpler end, the software platform introduces customers to a payment provider.

The provider may:

• contract directly with the merchant;

• set merchant pricing;

• complete underwriting;

• manage payment processing; and

• provide the regulated payment service.

The software company may then receive an agreed referral payment or ongoing share of payment revenue.

This can be relatively simple operationally.

However, the platform may have less control over:

• customer pricing;

• branding;

• onboarding;

• payment experience;

• commercial margin; and

• the long-term payment relationship.

For some platforms this is enough.

For others, particularly those with a significant existing customer portfolio, it may leave part of the commercial opportunity untapped.

Find Your New Processor

What Is a Buy-Rate or Wholesale Embedded-Payments Model?

A buy-rate or wholesale model can give the platform greater participation in payment economics.

Broadly, the platform agrees underlying payment economics with the payment partner and then offers payment processing to its customers under the commercial structure supported by that provider.

Where the model permits the platform to control customer pricing, the difference between the underlying payment economics and customer price can create margin.

Conceptually:

Customer payment price
– underlying payment cost
= potential platform payment margin

The actual calculation is more complicated because payment costs can include:

• interchange;

• scheme fees;

• acquiring margin;

• gateway charges;

• transaction fees;

• card type;

• international cards;

• cross-border fees;

• alternative payment methods;

• refunds;

• chargebacks; and

• additional services.

But the principle matters.

If a software platform has a substantial existing customer portfolio processing significant payment volume, even a relatively small net margin across that portfolio can become commercially meaningful.

Stripe, for example, currently documents both a referrer-style model and a wholesale/buy-rate model for SaaS platforms using Connect, while its platform-pricing tools can support application fees in eligible configurations. Worldpay for Platforms currently describes configurable payment fees, and Adyen for Platforms describes SaaS models where platforms can control transaction pricing.

These examples demonstrate why the commercial model should be negotiated as part of the wider platform strategy.

They do not mean those providers will be suitable for every platform.

The MAS Embedded Payments Opportunity Test

Before approaching payment providers, we recommend establishing the commercial size of the opportunity already inside your customer base.

A simple first-stage model is:

Step 1: Estimate addressable payment volume

Number of active business customers
× expected payment adoption
× average monthly payment volume per customer
= potential monthly platform payment volume

Then:

Potential monthly payment volume × 12
= potential annual platform payment volume

Illustrative Example

Imagine a software platform has:

• 1,000 active business customers;

• 50% expected payment adoption; and

• average monthly payment volume of £30,000 per participating customer.

That produces:

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

Or:

£180 million potential annual payment volume

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

Adoption, merchant eligibility, customer behaviour and provider acceptance all affect the actual outcome.

But it changes the conversation.

A software company potentially bringing £180 million of annual payment volume to a provider should understand the value of that portfolio before negotiating the commercial arrangement.

Step 2: Model Potential Payment Revenue

Once potential payment volume is understood, different commercial scenarios can be modelled.

Broadly:

Addressable annual payment volume
× potential net platform margin
= indicative annual payment opportunity

For example, a business could model several hypothetical net-margin scenarios to understand the sensitivity of the opportunity.

This is a commercial planning exercise, not a revenue forecast or guarantee.

Actual net margin will depend on:

• customer adoption;

• provider pricing;

• card mix;

• international transactions;

• payment methods;

• refunds;

• chargebacks;

• support costs;

• commercial structure; and

• other fees.

MAS View

Model the payment opportunity before negotiating with providers.

It is difficult to assess whether a proposed revenue share, buy rate or platform pricing structure is genuinely competitive if you do not first understand the potential value of the customer portfolio you are bringing.

This is one of the most important differences between approaching embedded payments as an API project and approaching it as a payments strategy project.

Do We Need to Become a PayFac to Offer Embedded Payments?

No - not necessarily.

A traditional Payment Facilitator model can give a platform considerable control over merchant onboarding and payment activity, but it can also involve substantially greater responsibility.

Modern platform-payment structures can allow software businesses to offer deeply integrated or white-labelled payment experiences while an underlying authorised provider handles significant elements of the regulated payment infrastructure.

Depending on the model, the underlying provider may handle areas including:

• merchant verification;

• KYB/KYC;

• underwriting;

• payment processing;

• acquiring;

• settlement;

• fraud monitoring;

• chargebacks; and

• other payment-provider responsibilities.

Some models give the platform considerably more involvement than others.

For many established software businesses, the first question should therefore be:

“How much payment responsibility do we actually want?”

rather than:

“How do we become a PayFac?”

Who Is the Merchant in an Embedded-Payments Model?

This should be established early.

Imagine a booking platform used by hotels.

The roles may broadly look like this:

Booking platform
Provides the software.

Hotel
Provides accommodation or other services to the end customer.

Guest
Pays the hotel.

The payment structure then determines how the hotel is onboarded, who provides payment services and how funds flow.

In many platform models, individual businesses using the software remain the merchants accepting payments from their customers.

Marketplaces can introduce a different level of complexity because funds may need to be allocated between multiple sellers, service providers or other parties.

If your platform handles multi-party payment flows, read our Split Payment Gateways: A Complete Guide for Marketplaces and Platforms.

Are Embedded Payments Regulated?

Payments are regulated activities, but embedding payment technology into software does not by itself determine the regulatory status of the software business.

The structure matters.

The Financial Conduct Authority explains that activities including execution of payment transactions and acquiring payment transactions are payment services under the UK Payment Services Regulations.

The FCA also specifically warns that online marketplaces, businesses bringing sellers and customers together and booking businesses may need to consider whether their activities amount to providing payment services — particularly where they receive customer money before passing it to another party.

Businesses considering embedded payments should establish:

• who provides the regulated payment service;

• who contracts with the merchant;

• who receives or controls funds;

• who completes merchant verification;

• who is responsible for settlement;

• who handles merchant risk;

• who manages chargebacks;

• who carries negative balances or losses;

• what responsibilities sit with the platform; and

• what regulatory permissions or exclusions may apply.

The relevant FCA guidance should be reviewed as part of the planning process, and specialist legal or regulatory advice should be obtained where required.

MAS does not provide legal or regulatory advice.

Find Your New Processor

What Should a SaaS Platform Negotiate With an Embedded-Payments Provider?

Do not evaluate an embedded-payments partnership on API functionality alone.

For an established platform, the commercial contract can ultimately be as important as the technology.

1. Pricing and Margin

Understand:

• the underlying payment economics;

• whether a buy-rate model is available;

• whether the platform can influence or set customer pricing;

• how the platform's revenue is calculated;

• whether fees are fixed, percentage based or both;

• how international cards are priced;

• whether gateway charges are separate;

• whether pricing improves with volume;

• whether there are minimum commitments;

• what additional services cost; and

• how changes in scheme or interchange costs are treated.

2. Customer Relationship

Establish:

• who contracts with the merchant;

• whose brand the customer sees;

• whether the provider is visible;

• who provides payment support;

• who owns the relationship if the partnership ends;

• whether the payment portfolio can move elsewhere;

• how customer data can be accessed; and

• what happens if the platform later changes payment partner.

Customer ownership becomes increasingly important once the payment portfolio has meaningful commercial value.

3. Merchant Onboarding

Payment revenue depends on customers actually activating the service.

Ask:

• Can onboarding sit inside the software?

• Who collects KYB/KYC data?

• Who performs underwriting?

• How are referred applications handled?

• What happens when a merchant needs manual review?

• Which sectors are supported?

• Which sectors are restricted?

• How are declines communicated?

• Can onboarding status be returned through the API?

• Can existing customers be migrated efficiently?

An attractive payment margin is worth very little if customers cannot successfully onboard.

4. Payment Capability

Consider both today's requirements and the platform roadmap.

Does the provider support:

• online payments;

• in-person payments;

• recurring billing;

• card-on-file;

• Apple Pay and Google Pay;

• payment links;

• multiple currencies;

• international cards;

• alternative payment methods;

• refunds;

• chargebacks;

• split payments;

• multiple locations; and

• international expansion?

A platform should ideally avoid rebuilding its payment infrastructure every time the product proposition evolves.

5. Reporting and Data

Consider:

• transaction reporting;

• reconciliation;

• merchant-level reporting;

• payout reporting;

• refunds;

• chargebacks;

• payment fees;

• platform revenue;

• onboarding status;

• payment performance; and

• whether relevant data can be returned directly into the software.

Payments can potentially make the wider software product more useful — not merely more profitable.

What Is the Difference Between Embedded Payments and White-Label Payments?

Embedded payments describe payment functionality being integrated into the software experience. White-label payments generally describe payment functionality being presented under the platform's own brand.

The two frequently overlap.

A payment proposition can therefore be:

• embedded but provider-branded;

• embedded and partly white-labelled;

• deeply integrated and predominantly platform-branded; or

• structured differently depending on the provider.

The more important questions are:

Who owns the customer relationship?

Who provides the regulated service?

Who controls pricing?

Who handles onboarding?

Who carries risk?

Who receives the commercial payment revenue?

For more detail, read What Is White-Label Merchant Processing? A Guide for Platforms and SaaS Companies.

Embedded Payments vs Integrated Payments: What's the Difference?

There is no universally applied industry boundary between the two terms.

Broadly, an integrated payment means payment technology communicates with another business system.

Embedded payments generally describe a deeper relationship where payments become part of the software proposition itself.

For a SaaS business, this may include:

• merchant onboarding within the platform;

• payments inside the software;

• payment reporting;

• pricing linked to the platform proposition;

• customer payment management;

• platform payment revenue; and

• a more unified user experience.

Rather than focusing too heavily on terminology, businesses should compare the actual commercial, contractual and technical structure.

You can also read our guide on how ISVs can benefit from integrated payments.

How Much Can a SaaS Business Make From Embedded Payments?

There is no responsible universal embedded-payments revenue figure.

The economics depend on:

• number of customers;

• payment adoption;

• processing volume;

• transaction value;

• card mix;

• customer geography;

• payment methods;

• provider economics;

• platform pricing;

• refunds;

• chargebacks;

• support costs; and

• the negotiated commercial structure.

The right starting point is therefore not:

“What margin can we get?”

It is:

“How much payment volume already exists within our customer base?”

Use the MAS Embedded Payments Opportunity Test above to establish the approximate addressable volume before negotiating commercial terms.

MAS View

For a platform with hundreds or thousands of established customers, payments should be valued as a portfolio opportunity.

The larger the potential portfolio, the more important it becomes to understand pricing control, customer ownership, portability and long-term economics before signing a provider agreement.

Existing Customers vs New Customers: Where Should You Start?

There are usually two separate opportunities.

New Customers

Payments can be introduced during the normal software onboarding process.

This can simplify adoption because the customer is already configuring its platform account and payment requirements.

Existing Customer Portfolio

This can represent the bigger immediate opportunity — but migration requires more planning.

Understand:

• which providers customers currently use;

• whether existing contracts apply;

• whether stored payment credentials exist;

• what integrations customers rely on;

• whether the proposed pricing is competitive;

• what incentive customers have to move; and

• how migration can take place without unnecessary disruption.

For platforms with recurring-payment customers, read our guide to changing payment gateway and moving stored cards, tokens and recurring payments.

Embedded Payments for Booking Platforms

Booking technology is particularly suited to embedded payments because payment is naturally connected to the booking journey.

Examples include:

• hotels;

• restaurants;

• leisure;

• events;

• venues;

• travel;

• appointments;

• classes;

• memberships; and

• other reservation-led businesses.

A booking software business may already sit at the point where:

customer chooses service → booking is created → payment is required

Embedding payments can bring that transaction into the platform rather than requiring the merchant to build a separate payment relationship outside the software.

For a booking platform with a substantial customer base, that can create a meaningful commercial opportunity.

Read Payment Providers for Booking Systems: Everything You Need to Know.

Find Your New Processor

Embedded Payments for Subscription and Membership Platforms

Subscription platforms create another natural use case.

The technology may need to support:

• recurring card payments;

• tokenisation;

• card updates;

• retries;

• failed-payment recovery;

• subscription changes;

• cancellations;

• international billing; and

• reporting.

When payments sit inside the platform, these functions can become part of the software workflow rather than a separate payment system.

Read our Subscription Payment Processing: A Comprehensive Guide for Businesses.

What Can Go Wrong With an Embedded-Payments Strategy?

Embedded payments can create value, but they also create dependency.

Common mistakes include:

Choosing on API Quality Alone

A strong integration does not compensate for weak commercial terms.

Focusing Only on the Initial Processing Rate

Understand what happens to pricing as payment volume, card mix and geography change.

Not Valuing the Customer Portfolio First

If you do not understand the payment volume you can potentially bring, it is difficult to judge the commercial offer you receive.

Ignoring Customer Ownership

Understand what happens to the payment portfolio if you change partner later.

Underestimating Onboarding

Payments only generate value when customers successfully adopt them.

Assuming Every Customer Will Be Accepted

Provider underwriting and sector appetite still apply.

Ignoring Specialist Sectors

A platform serving several industries may find that provider appetite differs considerably between customer groups.

Building Only for Today's Geography

Expansion can change acquiring, currency, payment-method and regulatory requirements.

Accepting More Responsibility Than the Business Wants

Greater control can also create greater operational and regulatory responsibility.

The strongest embedded-payment structure is therefore not automatically the model giving the platform maximum control.

It is the model providing the right balance of commercial value, flexibility, customer experience and responsibility.

What Should You Know Before Approaching Embedded-Payments Providers?

Before provider discussions begin, map the opportunity.

Customer Portfolio

Know:

• number of active customers;

• customer sectors;

• customer locations;

• customer size;

• current payment providers; and

• expected growth.

Payment Opportunity

Estimate:

• total potential payment volume;

• payment adoption;

• average transaction value;

• online vs in-person volume;

• recurring-payment volume;

• currencies;

• international cards; and

• required payment methods.

Technology

Map:

• software architecture;

• API requirements;

• onboarding journey;

• reporting;

• webhooks;

• tokenisation;

• customer portal;

• mobile requirements; and

• available development resource.

Commercial Goals

Decide what you actually want:

• referral revenue;

• revenue share;

• buy-rate economics;

• control over customer pricing;

• white-label branding;

• customer ownership;

• existing-customer migration; and

• long-term scalability.

Operational Requirements

Understand:

• underwriting;

• merchant support;

• chargebacks;

• fraud;

• compliance;

• settlement;

• reconciliation;

• customer complaints; and

• regulatory responsibilities.

That creates a considerably more valuable provider conversation than simply asking:

“Can you send us your embedded-payments API?”

How Merchant Advice Service Helps With Embedded Payments

Merchant Advice Service approaches embedded payments as a commercial and payments-strategy project first, and a provider-selection exercise second.

1. We Assess the Existing Opportunity

We look at:

• your software;

• existing customer base;

• customer sectors;

• geography;

• potential adoption; and

• estimated payment volume.

2. We Help Define the Commercial Model

That may involve:

• referral revenue;

• revenue share;

• embedded payments;

• white-label payments;

• buy-rate and margin models; or

• another provider-supported platform structure.

We do not assume that becoming a traditional PayFac is the right outcome.

3. We Work Through the Technical Requirements

That could include:

• APIs;

• onboarding;

• recurring billing;

• reporting;

• wallets;

• international payments;

• customer migration;

• split payments; and

• other platform requirements.

4. We Consider the Commercial Structure

We help you think about the payment opportunity commercially, rather than simply comparing transaction rates.

That includes understanding the potential value of the portfolio before provider negotiations begin.

5. We Identify Relevant Payment Routes

Providers differ in:

• technology;

• platform structure;

• pricing models;

• underwriting appetite;

• geography;

• merchant onboarding;

• risk allocation; and

• commercial terms.

MAS can help identify the routes that warrant further discussion based on your requirements.

6. We Make the Introduction

Where appropriate, we introduce the business directly to the relevant payment provider.

The payment-processing relationship and applicable contracts remain directly between the relevant businesses and provider.

7. We Remain Available

If questions arise during the process or you want to review the strategy again as your platform grows, MAS remains available.

Read more about How Merchant Advice Service Works, How MAS Researches and Compares Payment Providers or explore the wider Payments Strategy Library.

Find Your New Processor

Have an Existing Customer Portfolio?

If your software or platform already serves an established base of businesses accepting payments elsewhere, there may be a commercial payment opportunity sitting inside your business today.

Before approaching providers individually, understand:

• potential payment volume;

• customer payment requirements;

• likely adoption;

• the commercial model you want;

• the underlying payment economics;

• customer pricing;

• who controls merchant onboarding;

• customer ownership;

• technical requirements;

• regulatory responsibilities; and

• how the model could scale.

MAS View

Do the commercial modelling before choosing the provider.

Once a platform understands the value and complexity of the payment portfolio it could create, it is in a much stronger position to evaluate potential payment partnerships.

Sources & Further Reading

This guide has been informed by UK regulatory guidance, current provider documentation and Merchant Advice Service research into platform payments.

Primary and Regulatory Sources

Financial Conduct Authority — Payment Services Regulations 2017 and Electronic Money Regulations 2011
FCA guidance covering what constitutes a payment service and which businesses may need authorisation or registration.

Financial Conduct Authority — Consider if You Provide Payment Services
Particularly relevant to marketplaces, booking businesses and organisations receiving customer money before passing it to another party.

Stripe Connect — Build a SaaS Platform
Current Stripe documentation describes SaaS platform models including referrer and wholesale/buy-rate approaches and merchant-of-record responsibilities.

Stripe Connect — Platform Pricing Tools
Documentation covering platform processing fees and application-fee pricing functionality in eligible Connect configurations.

Adyen for Platforms — Embedded Payments
Adyen's current platform proposition describes white-labelled embedded payments, platform-controlled transaction pricing and payment monetisation.

Worldpay for Platforms — Configurable Fees
Worldpay describes platform functionality allowing businesses to define and configure payment fees and monetise embedded-payment services.

Ryft — Payment Solutions for Platforms and Marketplaces
Ryft's current platform proposition includes embedded payments, split payments, merchant onboarding and transaction monetisation.

Related Merchant Advice Service Guidance

• Payments Strategy Library

• How SaaS Platforms Can Offer Recurring Payments to Clients — and Monetise It

• What Is White-Label Merchant Processing?

• How ISVs Can Benefit from Integrated Payments

• Split Payment Gateways for Marketplaces and Platforms

• Payment Providers for Booking Systems

• Subscription Payment Processing

• Changing Payment Gateway: Stored Cards, Tokens and Recurring Payments

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 or provider capabilities included in this guide.

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

Providers named within this article are examples and do not represent a complete whole-of-market list or ranking.

Embedded, white-label, revenue-share and buy-rate models vary between providers. The availability of a particular commercial structure, integration, pricing model or level of platform control depends on provider capabilities, geography, merchant sectors, payment volume, underwriting appetite and the responsibilities agreed between the parties.

An embedded-payment solution does not guarantee that every merchant within a platform's customer portfolio will be accepted. Provider underwriting, prohibited and restricted sectors, risk appetite, geography and merchant eligibility vary.

Embedding payment functionality into software does not by itself determine the regulatory status or obligations of the platform. Businesses should establish which entity is providing regulated payment services and obtain specialist regulatory or legal advice where appropriate.

Merchant Advice Service does not make underwriting decisions or guarantee merchant-account acceptance.

Payment-provider capabilities, pricing, regulation, underwriting criteria and platform commercial models can change. This guide provides general information and should not be treated as legal, regulatory or financial advice.