Embedded Payments for SaaS, ISVs & Software Platforms

Embedded payments allow a software company, SaaS platform or digital product to make payment functionality part of its own customer proposition.

Instead of every customer independently finding a merchant account, choosing a gateway and connecting payments to the software, the platform can potentially bring those elements together.

A simplified journey might become:

software account → merchant onboarding → payments activated → customer takes payments → reporting and payment activity appear inside the platform.

But “embedded payments” can describe several very different commercial and technical models.

A platform might simply integrate a payment provider. It might negotiate revenue share. It could introduce a branded or white-label payment proposition. Larger platforms may explore Payment Facilitator models, multiple PSPs or more complex payment infrastructure.

This hub explains those options and links to the more detailed Merchant Advice Service guides for each part of the decision.

Embedded payments or integrated payments?

These terms overlap, but keeping them separate makes the payment strategy much clearer.

Embedded payments generally describes payments becoming part of a software company's own product or platform proposition.

Integrated payments is the broader concept of connecting payment acceptance with the software a merchant already uses, such as EPOS, ERP, CRM, booking or accounting systems.

So:

Software platform offering payments to its customers → Embedded Payments

Merchant connecting its own payment provider to its business systems → Integrated Payments

If you are a merchant trying to connect payments with EPOS, ERP, CRM or other business software, read our Integrated Payments guide instead.

Who are embedded payments for?

Embedded payments are most relevant where a software company already serves businesses that need to accept payments as part of the workflow.

Examples can include:

• vertical SaaS businesses;
• Independent Software Vendors (ISVs);
• booking and reservation platforms;
• hospitality software;
• healthcare and practice-management systems;
• fitness and membership platforms;
• property-management software;
• education platforms;
• field-service software;
• retail and EPOS platforms;
• marketplaces;
• professional-services platforms; and
• other software businesses whose customers already accept payments.

The opportunity becomes more interesting when the software company already has an established merchant customer base and meaningful payment volume is passing through those businesses.

The starting question should therefore be:

How much payment activity already exists across our customer base, and how much of the payment experience do we actually want to own?

Explore the embedded payments landscape

Embedded payments can be structured in several ways. Use the guides below to go deeper into the part of the model that matters to your platform.

What does an embedded payment model actually include?

There is no single embedded-payment structure.

Depending on the platform and provider, the model may include some or all of the following:

• merchant onboarding inside the software;
• KYB and KYC information collection;
• payment acceptance inside the product;
• integrated online payments;
• integrated card terminals;
• payment links;
• recurring payments;
• stored payment methods;
• refunds;
• payment reporting;
• settlement information;
• reconciliation;
• merchant support;
• pricing controlled or influenced by the platform;
• revenue share;
• white-label branding; and
• other commercial participation in payment processing.

The more of that experience the software company controls, the more important it becomes to understand where the underlying payment-provider responsibilities begin and end.

Ways a software company can offer payments

Embedded payments should not automatically be interpreted as becoming a Payment Facilitator.

There is a spectrum of models.

1. Referral relationship

The platform introduces customers to a payment provider, but the provider owns most of the payment journey.

This can be relatively simple but gives the software business limited control.

2. Integrated payment partnership

The payment provider is integrated directly into the software and merchants may be able to activate payment services as part of their use of the platform.

The provider can remain visible and retain responsibility for underwriting, contracts, settlement and much of the merchant relationship.

For this model, see our ISV Integrated Payments guide.

3. Embedded payment model

Payments become a more substantial part of the software proposition.

The platform may influence or control more of:

• merchant onboarding;
• payment user experience;
• payment reporting;
• pricing presentation;
• merchant communications;
• support; and
• payment-related revenue.

4. White-label processing

More of the payment proposition may appear under the platform's own branding.

This does not necessarily mean the software business itself becomes the underlying acquirer or regulated payment institution.

Read our White-Label Merchant Processing guide for the deeper commercial and branding considerations.

5. PayFac or managed PayFac

Platforms seeking greater control over merchant onboarding and the payment relationship may consider a Payment Facilitator structure or a managed PayFac-style model.

These structures can introduce substantially more operational, risk and regulatory complexity.

Read our Payment Facilitator guide.

Start with the existing merchant portfolio

For an established SaaS business or ISV, the most useful starting point is usually the payment opportunity already sitting inside its customer base.

Understand:

• number of active software customers;
• number currently accepting payments;
• average monthly payment volume per customer;
• total estimated portfolio volume;
• average transaction value;
• online versus face-to-face payments;
• recurring-payment volume;
• customer sectors;
• customer countries;
• currencies;
• refund levels;
• chargeback profile; and
• expected customer growth.

This tells the platform far more than asking a provider:

“What revenue share can you offer us?”

The commercial opportunity should be assessed from the underlying portfolio rather than an unsupported margin assumption.

Provider risk appetite matters as much as the API

A technically strong embedded-payment integration has limited value if the payment partner cannot accept a significant proportion of the platform's merchants.

Before choosing a provider, understand the actual portfolio.

Ask:

• Which merchant sectors are supported?
• Are any industries restricted?
• Which countries can merchants be registered in?
• Which customer geographies are supported?
• Are there transaction-value limits?
• Can high-risk merchants be considered?
• What happens to merchants that fail automated underwriting?
• Can manual underwriting be supported?
• What information is required at onboarding?
• How are declined merchants handled?

Provider fit should be tested against the platform's real customer base, not an idealised merchant profile.

Merchant onboarding is part of the product

One of the biggest differences between a simple payment integration and a deeper embedded model is how merchants are activated.

A platform may want a journey such as:

create software account → enter business information → KYB/KYC → underwriting → merchant approved → payments activated.

Important questions include:

• Who collects merchant information?
• Is onboarding provider-hosted or embedded?
• Who performs KYB and KYC?
• Who makes the underwriting decision?
• How are requests for further information presented?
• What happens when a merchant is declined?
• Who owns ongoing monitoring?
• Who handles merchant updates?
• How long does activation normally take?

A seamless software interface cannot remove the underlying requirement for proper merchant onboarding and underwriting.

How do software platforms make money from embedded payments?

There is no single embedded-payment revenue model.

Depending on the payment partnership, commercial structures may include:

• referral payments;
• revenue share;
• agreed payment margin;
• platform payment fees;
• white-label pricing models;
• commercial incentives linked to processing volume; or
• other negotiated arrangements.

The revenue opportunity depends on factors including:

• merchant adoption;
• portfolio volume;
• transaction mix;
• provider economics;
• merchant pricing;
• customer geography;
• payment methods;
• support costs;
• chargeback and risk costs;
• contract terms; and
• the level of responsibility the platform takes on.

Our ISV Payments guide looks more closely at portfolio economics, payment partnerships and revenue models.

Embedded payments do not have to be fully white-labelled

Branding exists on a spectrum.

A payment experience might be:

• clearly provider-branded;
• co-branded;
• embedded within the software interface;
• predominantly platform-branded; or
• structured as a deeper white-label proposition.

The software company should not assume that more white-labelling is automatically better.

Greater ownership of the customer experience can also create greater expectations around:

• merchant support;
• pricing enquiries;
• payment disputes;
• technical support;
• onboarding problems;
• service outages; and
• account terminations.

The White-Label Merchant Processing guide goes deeper into this model.

What technology is needed for embedded payments?

The technical architecture depends heavily on the model.

Components may include:

• payment APIs;
• SDKs;
• hosted or embedded payment components;
• merchant-onboarding APIs;
• webhooks;
• tokenisation;
• card-terminal integrations;
• refund functionality;
• recurring-payment functionality;
• reporting APIs;
• settlement data;
• merchant dashboards;
• fraud tools; and
• developer environments.

The software should be designed around more than the successful transaction.

It also needs to account for events such as:

• declines;
• refunds;
• partial refunds;
• chargebacks;
• failed recurring payments;
• merchant account restrictions;
• settlement changes;
• provider outages; and
• merchant termination.

For the deeper technical considerations, read our Payment API Integration guide.

Payments should improve the software workflow

The strongest embedded-payment propositions normally make payments part of something the software already helps the customer do.

For example, booking software might move from:

booking created → customer asked to pay elsewhere → staff manually update booking.

to:

booking created → deposit calculated → payment taken → booking confirmed → payment recorded → balance collected later.

A membership platform could connect:

member joins → payment method stored → membership activated → recurring payments collected → failed payment triggers account workflow.

The embedded-payment decision should therefore start with the customer's software journey rather than a generic list of gateway features.

Embedded payments for marketplaces are a separate payment challenge

A marketplace may need more than straightforward payment acceptance.

The customer might make one payment while the platform needs to:

• identify the seller;
• deduct commission;
• split funds;
• manage payouts;
• onboard multiple sellers;
• manage reserves or risk;
• support refunds;
• deal with disputes; and
• maintain transaction records across multiple parties.

This creates a very different funds-flow requirement from a SaaS platform whose customers simply need their own merchant accounts.

Read our Split Payment Gateways guide for the marketplace-specific structure.

Does offering embedded payments make a software company a regulated payment provider?

Not automatically.

A software platform can integrate or distribute another provider's payment service without necessarily becoming a regulated payment institution itself.

However, the regulatory analysis depends on what the platform actually does.

The FCA states that businesses providing payment services as a regular occupation or business activity in the UK generally need the appropriate authorisation or registration unless an exemption or exclusion applies.

The question becomes particularly important if the platform itself begins:

• receiving customer money;
• holding or controlling funds;
• transferring money between parties;
• operating payment accounts;
• providing acquiring or other regulated payment services; or
• performing activities that may fall within the UK payments regulatory perimeter.

The FCA specifically highlights marketplaces and other businesses that bring buyers and sellers together as models that may need to consider whether they are providing payment services.

Platforms considering these structures should obtain appropriate regulatory advice rather than assuming the technical payment model determines the regulatory position.

Does a software platform need to become a Payment Facilitator?

No.

A platform can create a meaningful embedded-payment proposition without becoming a traditional full Payment Facilitator.

The underlying model might instead involve:

• a PSP partnership;
• an acquiring partnership;
• a referral or revenue-share model;
• embedded merchant onboarding;
• white-label infrastructure;
• managed PayFac arrangements;
• PayFac-as-a-Service; or
• another provider-led structure.

The better question is:

Which parts of the payment relationship create enough strategic value for the software company to justify owning them?

Our Payment Facilitator guide explains the operating model in more detail.

Should an embedded-payment platform use one provider?

For many platforms, starting with one strong payment partner can make sense.

Potential advantages include:

• one integration;
• simpler onboarding;
• consistent commercial terms;
• one support relationship;
• simpler reporting;
• one merchant experience; and
• a clearer technical roadmap.

But dependence on one provider can become more significant as the platform grows.

One provider may not support:

• every merchant sector;
• every country;
• every currency;
• every payment method;
• every acquiring model;
• high-risk customers;
• marketplaces; or
• future products the platform wants to launch.

Larger platforms may therefore eventually explore additional PSPs, acquirers or more flexible gateway architecture.

For wider complex-payment architecture, see the Payment Gateways hub.

Provider lock-in should be considered before building

An embedded-payment integration can eventually become one of the deepest dependencies inside a software platform.

Over time, the platform may accumulate:

• thousands of onboarded merchants;
• stored payment tokens;
• recurring payments;
• installed terminals;
• payment pricing arrangements;
• merchant reports;
• refund workflows;
• support procedures;
• settlement data; and
• significant payment revenue.

Before committing to a provider, establish:

• whether merchant data is portable;
• whether payment tokens can be migrated;
• who controls merchant contracts;
• whether the relationship contains exclusivity;
• what happens to merchant pricing if the partnership ends;
• who owns installed hardware;
• how migration would work; and
• whether another provider can be added later.

A slightly less attractive commercial offer today can sometimes create substantially greater strategic flexibility later.

How should a platform compare embedded-payment providers?

There is no single provider that is right for every software platform.

Merchant fit

Can the provider support the actual sectors, locations and transaction profiles within the customer portfolio?

Onboarding

How are KYB, KYC, underwriting, activation and declined merchants handled?

Technical capability

Review APIs, SDKs, webhooks, tokens, terminals, recurring payments, refunds and developer tooling.

Commercial model

Understand merchant pricing, platform economics, revenue share, minimum commitments and how commercial terms can change over time.

Branding

How visible is the payment provider and how much of the payment proposition can sit under the platform's own brand?

Support

Who supports merchants, payment integrations, disputes, settlement questions and outages?

Risk

Who owns underwriting, fraud controls, chargebacks, reserves and ongoing monitoring?

Settlement

Who settles merchants and what information can the platform and merchant see?

International capability

Check countries, currencies, local acquiring and payment methods required by the customer base.

Future flexibility

Can the platform add products, countries or another provider without rebuilding the entire payment layer?

How Merchant Advice Service helps with embedded payments

Merchant Advice Service approaches embedded payments as a payment-strategy and provider-fit exercise rather than simply recommending a gateway.

For a software platform, that can involve understanding:

• software product;
• customer portfolio;
• merchant sectors;
• portfolio payment volume;
• transaction values;
• payment channels;
• countries and currencies;
• merchant onboarding;
• provider risk appetite;
• commercial objectives;
• revenue-share requirements;
• branding;
• white-label requirements;
• PayFac ambitions;
• APIs and integrations;
• card-present requirements;
• recurring payments;
• marketplace or split-payment requirements;
• support ownership;
• international expansion; and
• future provider flexibility.

We can then help identify payment providers and embedded-payment partners that may fit the required structure.

Merchant Advice Service does not act as an acquiring bank, Payment Facilitator, processor or regulatory adviser.

Where should you go next?

Software company exploring payment partnerships?
Read the ISV Integrated Payments guide →

Want payments under your own brand?
Explore White-Label Payment Processing →

Considering a PayFac model?
Understand Payment Facilitators →

Building the technical integration?
Read the Payment API Integration guide →

Operating a marketplace or platform with multiple sellers?
Explore Marketplace & Split Payments →

Merchant connecting payments with its own software?
Go to Integrated Payments →

Ready to compare embedded-payment partners?
Find Embedded Payment Providers →

Sources & References

• Financial Conduct Authority – Payment Services Regulations 2017 & Electronic Money Regulations – overview of UK payment-service regulation and when authorisation or registration may be required.
• Financial Conduct Authority – Consider Whether You Provide Payment Services – FCA guidance for marketplaces, booking businesses and other platforms that may receive or transfer customer money.
• PCI Security Standards Council – PCI DSS – requirements relating to organisations that store, process or transmit payment card account data.
• Merchant Advice Service – Integrated Payments for ISVs – guidance on payment partnerships, merchant portfolios, revenue models and provider selection for software companies.
• Merchant Advice Service – Payment Facilitators – detailed guidance on PayFac structures and sub-merchant models.
• Merchant Advice Service – White-Label Merchant Processing – guidance on branded payment propositions for platforms and SaaS companies.
• Merchant Advice Service – Payment API Integration – technical guidance on APIs and payment integrations.
• Merchant Advice Service – Split Payment Gateways – guidance for marketplaces and multi-party payment flows.
• Merchant Advice Service – Editorial & Research Policies – information about how MAS researches and reviews payment information.

Editorial & Commercial Disclosure

This guide explains embedded-payment models for software companies and platforms. Embedded-payment terminology is not applied consistently across every payment provider, so businesses should compare the actual technical, commercial and contractual structure rather than relying solely on product labels.

Merchant Advice Service is an independent payments information and provider-matching service. MAS is not an acquiring bank, Payment Facilitator, payment processor or regulatory adviser.

There is no single embedded-payment model or provider that is suitable for every software platform. The appropriate structure depends on the platform's customer portfolio, merchant sectors, transaction volumes, technology, commercial objectives, regulatory position and level of operational responsibility.

MAS may receive a referral fee or commission from some payment providers where a business proceeds following an introduction. Commercial relationships do not determine the factual information or provider-selection principles contained within this guide.

Platforms considering whether their activities fall within UK payment-services regulation should obtain appropriate legal or regulatory advice. Final provider approval, technical implementation, underwriting, commercial terms and regulatory responsibilities remain with the relevant organisations.