Embedded Payments for UK Software Platforms: How They Work and Which Route Fits

If you run a software platform, your customers almost certainly take payments already. They just don't take them through you. The bookings, memberships or invoices live in your software, while the money goes through a card machine, a gateway or a Direct Debit bureau they picked themselves.

Embedding payments brings that money inside your product and let you earn a fee on it. The rails are the easy part. The route you choose decides who holds the money, who carries the risk, and whether your existing customers ever actually move.

If you are a business looking for a checkout on your own website, rather than a platform adding payments for your customers, see our page on website payments instead.

What are embedded payments?

Embedded payments are payment acceptance built directly into a software platform. The business using the software onboards, takes payments, gets paid out and reconciles, all without leaving the product.

The opposite is the link-out model. Your software records the booking or the invoice, then hands the customer to a separate gateway that the business signed up to on its own.

For the businesses using your platform, the change usually means:

• One place to work. Bookings, invoices and payments sit in the same system, with one login and one support contact.
• Payments matched to the record. Each payment lands against the booking, membership or invoice it belongs to, not as an unmatched line on a bank statement.
• Money that collects itself. Card on file, automatic charging and retries mean fewer chasers and fewer missed payments.
• Every payment method on one account. Cards, Apple Pay, Google Pay, pay by link, card machines and Direct Debit, without three separate providers.
• One statement. Payouts arrive on a set schedule with a statement the business can actually read.

In practice, the business rarely thinks of this as "payments". It thinks of it as the software finally doing the whole job.

Platforms usually rely on infrastructure providers such as Stripe or Adyen underneath. What differs between routes is how much of the work, risk and regulation the platform takes on itself.

For your platform, the shift is just as significant. Payment data sits next to your booking and billing data. That makes features like automatic reminders, failed-payment handling and revenue reporting far easier to build well.

How software platforms make money from embedded payments

When payments run through your platform, you can add your own fee to each one. That fee becomes a revenue line that grows as your customers sell more, without a price rise on your software.

Per transaction. A small fee or percentage on every payment. It scales directly with your customers' trading volume.

Per customer. A flat monthly payments fee per business. Predictable for you, and easy for customers to understand.

Per plan. Payments bundled into a higher software tier. This suits platforms that would rather sell one combined price than a separate payments line.

On a well-set-up route, your fee is split out of each payment as it lands and credited to you. There is nothing to invoice and nothing to chase. Refunds and disputes split the same way, so your share adjusts automatically.

Pricing has to start from how your customers pay today. Card payments are usually charged as a percentage. Direct Debits are usually charged in pence per item. A single blended rate rarely suits both.

The strongest offers combine software and payments into one price list for each type of customer. A small club and a large multi-site operator should not see the same payments price, because they do not trade the same way.

Referral deals work differently. A payment provider pays you a small fee for introducing a customer, usually only on customers you convert yourself. You earn something, but you do not control the price and you do not own the revenue line.

Here is the reality check most platforms miss. The revenue does not come from launching payments. It comes from how many of your existing customers actually move onto them.

What usually happens is that new sign-ups adopt payments and the established base, where most of the volume sits, stays exactly where it was. A platform in that position has a feature, not a revenue line.

The four routes for a UK platform

A UK platform has four realistic ways to make money from its customers' payments. They differ on who holds the funds, who carries the risk, and who does the work of moving customers across.

Route	What you get	Who holds funds and carries risk	Who moves your customers	Usually fits
Referral deal	A small fee for each customer you introduce	The payment provider	You, one customer at a time	Platforms that want low effort and accept low income
Self-serve platform payments (for example Stripe Connect)	The tools to take payments inside your product and add a fee	The provider, with some risk shared with you by contract	You: pricing, messaging, onboarding and chasing	New platforms, or teams with capacity to run migration themselves
Managed embedded payments	Payments in your product under your brand, your fee on every payment, and the migration run for you	A regulated acquiring partner; each business holds its own balance	The partner, in your name, group by group	Platforms with an existing customer base already paying elsewhere
Becoming a registered PayFac	The most control over pricing, onboarding and margin	You, as the registered facilitator	You	Large platforms treating payments as a core business line

None of these is right for every platform. The main trade-offs look like this:

• Referral is easy but thin. You keep no control over pricing, and most of your book never moves because nobody is working on it.
• Self-serve gives you the rails, not the customers. The technology is excellent. The job of persuading established customers to switch stays with your team.
• Managed puts the migration work first. It suits platforms where the money is in the existing book, not in new sign-ups.
• PayFac is a business in its own right. It brings underwriting, risk monitoring, disputes and settlement in-house. Few platforms need it.

Skip referral if payments could matter. If payments could become a meaningful share of your revenue, a referral fee leaves most of that value with the provider. It also gives you no say in how your customers are treated.

Self-serve alone struggles with a large book. If you have hundreds of established customers and no team to run campaigns, self-serve tends to produce a payments option that few of them use.

Managed needs a book to move. If none of your customers take payments yet, or most of them sit outside the UK, a managed UK route has nothing to work with.

A PayFac needs a permanent risk function. If your platform is not ready to run underwriting, risk and disputes as a permanent function, the registration is the start of the cost, not the end.

A common mistake is choosing on headline processing cost alone. The route that costs slightly more per transaction but moves most of your customers usually earns far more than the cheapest rail with low adoption.

What is a PayFac, and do you need to become one?

A payment facilitator, or PayFac, is a business registered with the card schemes through a sponsoring acquirer. It onboards other businesses as sub-merchants under its own master merchant account.

Becoming one means taking on the work an acquirer would normally do. That includes underwriting each business, monitoring risk, handling disputes and managing settlement.

You also need the people and systems to do that work every day, not just at launch. In practice, platforms that explore becoming a PayFac often find the operational load is the real cost, not the registration.

Most UK platforms do not need to become one. If your goal is a payments revenue line and a better product for your customers, other routes deliver both without the registration.

PayFac-as-a-Service

PayFac-as-a-Service is the middle option. A provider is the registered PayFac and carries the scheme obligations, while your platform presents payments inside its own product.

• The provider carries registration and risk. Underwriting, scheme compliance and settlement sit with the provider.
• Your customers are usually sub-merchants. They sit under the provider's master account rather than holding their own merchant relationship.
• You still own the experience. Onboarding screens, pricing and support routes are typically yours to design.
• You still own adoption. The provider gives you a product. Getting your existing customers onto it remains your job.

That model removes most of the regulatory burden. It does not remove the commercial one.

PayFac vs ISO

The two terms often get mixed up. The difference is who holds the merchant relationship.

	PayFac	ISO (independent sales organisation)
Who the business contracts with	The PayFac, as a sub-merchant	The acquirer directly
Onboarding	Fast, under the PayFac's own account	A full merchant application to the acquirer
Who carries risk	The PayFac	Mainly the acquirer
Typical role	Platforms and marketplaces onboarding many small businesses	Sales and service partners reselling merchant accounts

For a software platform, neither label matters as much as the practical questions. Who holds the money, and who does the work of moving your customers?

Who holds the money and who carries the risk

This question decides whether a platform becomes a payments company by accident. Where the money sits between a customer paying and the business being paid out matters more than any feature list.

When your platform holds the funds. Money passes through an account you control before reaching the business. That can bring you into payment services regulation, with authorisation, safeguarding and reporting duties.

When the funds sit with a PayFac. The businesses using your software are sub-merchants of that PayFac. The PayFac carries the scheme liability, and can hold or release funds under its own rules.

When each business holds its own balance. Funds sit in a balance in each business's own name with a regulated acquirer. Your platform never touches the money and nobody is anyone else's sub-merchant.

Risk follows the money. On the cleanest routes, checks happen before a business goes live, based on how it actually trades.

The other test is what happens when something goes wrong. A common issue with self-serve payments is an account frozen by an automated system with nobody to call. When an account needs a closer look, a named person should give the reason and a timeline.

That matters to you as much as to your customer. A frozen account looks like your software has failed, and the support call lands with your team either way.

UK regulation: when FCA authorisation comes into it

In the UK, payment services are regulated under the Payment Services Regulations 2017. The FCA's position is that providing payment services without the correct authorisation or registration is a criminal offence.

Platforms that receive and pass on their customers' money are the ones most likely to be caught. Some exclusions exist, but they are narrow and depend on the specifics.

Platforms that never hold or control customer funds generally stay outside this. That is why the funds question belongs at the start of any payments decision, not at the end.

Settlement matters too. A UK-focused platform will usually want its customers paid in GBP on UK rails, with Direct Debit alongside cards. A provider built for international, multi-currency settlement is not always the best fit for a UK sports club or clinic.

Self-serve or managed: which suits your stage

The honest answer depends less on your technology and more on your customers. Specifically, whether you already have a book of businesses taking payments somewhere else.

Your platform	Usually the better fit	Why
New, with no customers taking payments yet	Self-serve platform payments	There is no book to move. Fast set-up and good developer tools matter most.
Growing, with engineers and a team to run campaigns	Self-serve, or managed in an advisory role	You can run the migration yourself if someone designs the pricing and plan.
Established, with customers paying through other providers	Managed embedded payments	The revenue sits in the existing book, and moving it is a dedicated job.
Very large, treating payments as a core product line	Becoming a PayFac may be worth weighing	Volume can justify building underwriting and risk in-house.

If you are building a new SaaS product, perhaps with AI tools and a small team, a mainstream self-serve option such as Stripe Connect is usually the right starting point. Integration is quick and the documentation is good.

The picture changes once you have hundreds of businesses already paying through someone else. Self-serve is not unsuitable because the technology is weak. For established platforms, it is unsuitable long-term because the rails do not move customers on their own.

Three questions place most platforms quickly:

• Is your platform the system of record for billing? If invoices, bookings or memberships live in your software, payments have a natural home there.
• How do your customers pay today? A percentage per card payment, pence per Direct Debit, or both. This shapes the price list you can offer.
• Who would feel a fee? The business using your software, or its own customers. A fee should never land on the member, patient or tenant.

Platforms with no existing customers taking payments are not a fit for a managed route yet. We would rather say that on the first call than sell you something you do not need.

Starting on self-serve does not lock you in. Plenty of platforms launch payments that way, then bring in help once the established book is large enough to justify a proper migration plan.

Why existing customers don't move on their own

Most platforms that add payments get a fraction of their customers across. The rest stay put, and rarely because the offer is bad.

They stay because nobody is employed to price each customer, write to them, onboard them and follow up. That work is where the money is, and most payment launches skip it.

The platforms that do this well never lead with "you must use our payments". They follow the same sequence:

• Lead with features only your payments can do. Card on file, automatic charging, retries, card fallback when a Direct Debit fails, one statement and reconciliation. These are the reasons businesses move.
• Make the old route the legacy route. New customers start on your payments by default. Existing customers keep working as they are until they choose to move.
• Add a third-party fee only if needed. A billing or gateway fee on payments that run through someone else can nudge uptake, waived on your own payments.
• Change contracts only at renewal. No mid-term changes to payment terms, and always with notice.

Switching cost is the real objection, not the rate. Businesses worry about losing saved cards and having to re-sign every Direct Debit.

Carrying saved cards and Direct Debit mandates across for them removes most of that objection. Done properly, the business barely notices the move.

Timing matters as much as the offer. The best moments to ask are the ones where a business already feels the pain:

• At sign-up. New customers start on your payments by default, so there is nothing to switch.
• After a failed payment. A missed Direct Debit or declined card is when automatic retries and card fallback make the clearest case.
• At contract renewal. A business coming off its current provider's term has a natural reason to review.
• When a new feature launches. Features that only work on your payments give existing customers a reason to move now rather than later.

Customer groups need different messages. A large multi-site operator will want to talk about rates and reconciliation. A small club wants to hear it will take ten minutes and nothing will break.

The common bad choice is forcing the switch. A platform that mandates its own payments overnight risks churn among exactly the customers it most wants to keep.

The operational work behind embedded payments

For the business using your software, the payment step feels simple. Behind that sits a set of jobs that someone has to do every day.

Onboarding and verification. Each business must be checked before it can take payments. Done inside your product, under your brand, it should feel like part of signing up.

Disputes and refunds. Customers dispute payments. Someone has to gather evidence, respond on time and keep the business informed.

Payment support. Questions about payouts, failed payments and card machines will arrive. If your support team takes them, your queue stops being about your software.

Reconciliation and payouts. Payments need to match invoices and arrive on a predictable schedule. Getting this wrong is the fastest way to lose a business's trust.

Card machines and in-person payments. Many vertical platforms need counter payments as well as online ones. Someone has to supply, set up and replace terminals, or enable Tap to Pay on a phone.

Engineering. Your developers need an SDK, clear documentation and a test environment. A payments engineer working alongside them shortens the build considerably.

We regularly see platforms underestimate the support side. Payment questions are urgent in a way software questions are not, because a business that cannot get paid stops trading.

What seems manageable on paper often becomes a support burden in practice. Before choosing a route, decide which of these jobs you want to keep and which you want a partner to carry.

What a sensible rollout looks like

A good rollout starts with your customers, not your code. Each stage should end with something written down that your platform keeps, whether or not you carry on with the partner.

• Discover. Review the product and the customer base. Group every customer by size and by how they take payments today.
• Listen. Speak to customers in each group before designing anything. Find out what would make them move, and when.
• Design. Set the pricing and the payment products worth building for each group, with a reason, a moment and a channel for each.
• Run. Campaigns, onboarding and follow-up, group by group, in your platform's name. New customers start on your payments by default.

The first phase is usually a discovery of around six weeks. It should end with a combined software and payments price list for each group of customers, not a generic rate card.

After that, you choose how much of the work your own team runs. Some platforms want a plan they execute themselves. Others want the campaigns run for them, or the payment products built alongside their developers.

That choice can change over time. Many platforms start with the work run for them, then bring more of it in-house as their own team grows.

A reality check on quotes: any number given before someone has seen your customers' statements is a guess. Ask for figures based on your own book.

How to evaluate an embedded payments partner

Most providers look similar on their websites. The differences show up in who does what once you are live.

• Who holds the funds. Ask exactly where money sits between payment and payout, and whose name it sits in.
• Who controls your fee. You should set your own fee, per plan, per customer or per transaction, and see it split out automatically.
• Onboarding inside your product. Check that businesses sign up under your brand, without being sent to a third-party site.
• Payment methods covered. Cards, Apple Pay, Google Pay, pay by link, Tap to Pay on a phone, card machines and Direct Debit on one account.
• Who handles disputes and support. Find out whether payment questions land with the provider or with your team.
• Help moving existing customers. Ask whether the partner will price, contact and onboard your current book, or only provide the rails.
• UK settlement. Confirm payouts in GBP on UK rails if your customers are UK businesses.
• How risk reviews work. Ask who you speak to when an account needs a closer look, and how quickly.
• What you keep if you leave. Check whether the pricing work, customer analysis and plans are yours to keep.

The mistake to avoid is evaluating on technology alone. Most modern providers can process a payment well. Far fewer will help you get your existing customers to use it.

Watch for a quote that arrives before any questions about your customers. A partner that has not asked how your customers pay today cannot know what payments are worth to you.

Ask for a straight answer on fit, too. A partner that says on the first call when it is not right for you is more trustworthy than one that says yes to everything.

Embedded payments examples in UK sectors

The model works best where the business already takes money in more than one way. These are the patterns we see most often in UK vertical software:

• Sports and golf clubs. Memberships by Direct Debit, plus card payments at the bar and pro shop, all on one account.
• Clinics. Deposits at booking, balances on the day, and no-show fees charged to a card on file.
• Venues and wedding booking. Deposits and staged balance payments that collect themselves on schedule.
• Self storage and lettings. Recurring rent and fees by Direct Debit, with card fallback when a payment fails.
• Trades and job management. Invoices paid by link, or by card on site through a phone or card machine.
• Driving instructors and riding schools. Lesson packages paid upfront, with cancellation charges handled automatically.

Marketplaces follow the same logic with one extra step. Payments are split between the marketplace and each seller, and sellers are onboarded and paid out inside the marketplace.

In each case, the software already holds the booking or the invoice. Payments simply let it finish the job.

FAQ

What is embedded finance and how does it work?

Embedded finance is the wider category of financial services built into non-financial software. It covers payments, but also lending, cards, accounts and insurance offered inside a product the business already uses.

Payments are the most common part of it, and usually the first step. A platform that already handles its customers' payments is well placed to add other financial products later.

Conclusion

Embedded payments can turn your customers' existing payment volume into a revenue line for your platform. The right route depends mostly on one thing: whether you already have customers taking payments somewhere else.

New platforms are usually best served by self-serve tools. Established platforms make their money by moving the existing book, and that takes a dedicated plan.