White-Label Payment Processing for SaaS & Platforms: Models, Pricing, Onboarding & Risk

White-Label Payments: The Quick Answer

White-label payment processing allows a software company, SaaS platform or marketplace to present some or all of a payment proposition under its own brand while relying on an underlying payments provider, gateway, acquirer or platform infrastructure to deliver the payment service.

However, “white-label payments” is not one standard technical, commercial or regulatory model.

A white-label arrangement might mean:

• a payment gateway displayed under the software company's brand;
• merchant onboarding embedded within the platform;
• branded payment dashboards and reporting;
• integrated online and card-present payments;
• a platform influencing or setting merchant pricing;
• revenue share on payment processing;
• a more deeply managed payment proposition;
• a managed Payment Facilitator arrangement; or
• a combination of these.

The most important questions are therefore not simply:

“Can this payment system be white-labelled?”

They are:

Who contracts with the merchant? Who underwrites them? Who provides the regulated payment service? Who controls pricing? Who owns support? Who carries risk? Who controls the payment data and tokens? And what happens if the partnership ends?

White-label payment solutions allow platforms and software businesses to present payment functionality as part of their own proposition, but the underlying technology and acquiring structure can vary considerably. Our Payment Gatewaysguide provides a broader overview of gateway models, integrations and provider selection.

This guide explains how software businesses should evaluate those questions before selecting a white-label payment partner.

Find Your New Processor

Who Is This Guide For?

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

This can include:

• vertical SaaS businesses;
• booking platforms;
• healthcare software;
• hospitality technology;
• property-management software;
• fitness and membership platforms;
• professional-services software;
• education platforms;
• field-service software;
• marketplaces;
• franchise-management software;
• ERP and CRM platforms;
• commerce software; and
• other software businesses considering payments as part of their product.

If you are earlier in the decision process and want to understand the broader models available, read our guide to integrated payments for ISVs.

What Does White-Label Payment Processing Actually Mean?

At its simplest, white-labelling means that technology supplied by another organisation is presented as part of your own proposition.

In payments, that can range from relatively light branding to a much deeper commercial payment product.

For example, a software platform might have:

• its own payment product name;
• its own branded merchant onboarding journey;
• payment functionality inside its software;
• its own payment dashboard;
• branded transaction emails;
• integrated payment terminals;
• its own merchant-facing payment pricing;
• first-line payment support;
• payment revenue generated from its customers; and
• an underlying third-party infrastructure provider that actually enables the transactions.

But not every provider offers every element.

This is why software companies should avoid treating “white-label” as a binary feature.

The better question is:

Which parts of the payment lifecycle can we control and brand?

White-Label Is Not a Regulatory Status

This distinction is important.

White-label describes the presentation and commercial structure of a payment proposition. It does not automatically determine which organisation is providing the regulated payment service.

A software platform can offer a highly branded payment experience while an authorised payment organisation, acquirer or other payments provider remains responsible for significant parts of the underlying service.

At the other end of the spectrum, a platform may choose a structure that gives it substantially more responsibility for merchants, payment activity and risk.

The Financial Conduct Authority's perimeter guidance distinguishes between businesses providing regulated payment services and businesses providing merely technical services.

The FCA also specifically notes that models involving “master merchants” or Payment Facilitators that contract with merchants for acquiring services can fall within acquiring activity, while merely providing technical processing, data storage, terminals or an online gateway does not itself constitute acquiring.

This is one reason a software company should establish its intended payment model before deciding how much of the service to white-label.

White-Label Gateway vs White-Label Merchant Processing

These terms are sometimes used as though they mean the same thing.

They do not necessarily.

White-label payment gateway

A provider may allow a company to brand gateway technology as its own.

This can include:

• hosted payment pages;
• virtual terminals;
• transaction dashboards;
• gateway reporting;
• API functionality;
• payment links;
• recurring-payment tools; and
• other gateway functionality.

NMI, for example, currently markets a white-label payment gateway supporting online, in-store, mobile and other payment environments.

That does not automatically mean the software company is also the merchant's acquirer or Payment Facilitator.

White-label merchant processing

A deeper arrangement can extend beyond gateway branding into areas such as:

• merchant acquisition;
• merchant onboarding;
• KYC and KYB;
• underwriting;
• pricing;
• settlement;
• merchant support;
• chargebacks;
• risk monitoring;
• terminal services; and
• commercial payment revenue.

Exactly which organisation performs each function depends on the provider and contract.

White-Label vs Integrated vs Embedded vs PayFac

The terminology around platform payments is inconsistent, so it is more useful to compare the practical responsibilities than rely entirely on labels.

Read our broader guide to embedded payments for SaaS and platforms for more detail on how these models overlap.

White-Label Payments Do Not Necessarily Mean the Provider Is Invisible

The existing industry terminology can create an unrealistic expectation that the underlying payments provider will never be visible to the merchant.

That is not always possible or desirable.

Depending on the model, the underlying organisation may still appear within:

• merchant terms and conditions;
• regulated disclosures;
• bank-account verification;
• KYC communications;
• settlement information;
• terminal documentation;
• chargeback correspondence;
• payment statements;
• compliance requests; or
• other merchant communications.

The software platform should therefore ask providers to show the complete merchant journey, not simply a branded demo screen.

Who Contracts With the Merchant?

This should be one of the first questions asked in any white-label payment project.

Possible structures include:

• the merchant contracts directly with the underlying payment provider;
• the merchant accepts payment terms embedded within the platform;
• multiple payment organisations appear within the contractual structure;
• the software company has a commercial agreement with the merchant while regulated payment services are provided separately; or
• a deeper PayFac-style structure is used.

The answer affects:

• merchant ownership;
• pricing;
• support;
• complaints;
• termination;
• risk;
• regulatory responsibilities;
• data;
• settlement; and
• what happens when the payment partnership ends.

Who Owns Merchant Onboarding?

Merchant onboarding is often one of the most important parts of a white-label proposition.

A merchant may need to provide:

• company information;
• business activity;
• directors;
• beneficial owners;
• identity information;
• bank-account details;
• trading addresses;
• website information;
• processing volumes;
• transaction values;
• payment channels;
• financial information where required; and
• supporting documentation.

Behind that journey are KYC, KYB, sanctions, fraud and underwriting processes.

Modern platform providers offer different approaches.

Stripe Connect, for example, currently supports Stripe-hosted, embedded and API-led onboarding approaches. Adyen for Platforms similarly supports hosted onboarding or an API-only journey where the platform builds its own UI.

The amount of branding control therefore needs to be balanced against:

• development resource;
• ongoing maintenance;
• changing verification requirements;
• customer experience;
• support workload; and
• responsibility for incomplete applications.

Merchant Onboarding Is More Than an Application Form

Successful white-label onboarding also needs to handle merchants that do not pass straight through the process.

The provider may request:

• additional ownership evidence;
• identity documents;
• proof of bank account;
• financial statements;
• website changes;
• licence or regulatory evidence;
• more information about products or services;
• transaction history;
• refund information; or
• further underwriting clarification.

The platform needs to decide who tells the merchant what is outstanding and how the merchant supplies it.

An onboarding flow that looks excellent for straightforward merchants can become frustrating if exception handling has not been designed properly.

Provider Risk Appetite Can Determine Adoption

For an established vertical SaaS business, this may be even more important than the API.

Imagine that a platform has 2,000 business customers.

A payment provider may offer:

• excellent APIs;
• full branding;
• good commercials;
• fast development support; and
• strong reporting.

But if the provider is only comfortable accepting 60% of the platform's customer portfolio, the payment opportunity becomes significantly smaller.

Before selecting a partner, map the existing merchant base by:

• industry;
• business type;
• geography;
• average transaction value;
• maximum transaction value;
• monthly payment volume;
• online versus card-present activity;
• future delivery;
• subscriptions;
• chargeback profile;
• products or services sold;
• licensing requirements; and
• existing payment provider.

The payment provider's underwriting appetite should then be compared against the actual portfolio.

Read our guide to payment-provider risk appetite.

How Do SaaS Platforms Make Money From White-Label Payments?

The commercial model varies considerably between providers.

Possible structures include:

• one-off referral payments;
• ongoing revenue share;
• a share of provider margin;
• transaction markups;
• wholesale or buy-rate pricing;
• platform fees;
• monthly payment-product fees;
• gateway revenue;
• terminal revenue;
• instant-payout revenue;
• value-added payment services; and
• a combination of these.

Stripe, for example, currently promotes Connect to software platforms as a way to monetise transactions through markup or revenue share and offer additional financial products.

The correct structure depends on the size of the platform, its payment volume, responsibilities and commercial negotiating position.

Calculate the Payments Opportunity Before Negotiating

A software company should understand the value of the payment portfolio before entering provider negotiations.

Consider an illustrative platform with:

• 1,000 business customers;
• £50,000 average monthly card turnover per customer; and
• 60% expected adoption of the platform's payment product.

Total theoretical annual payment volume:

1,000 × £50,000 × 12 = £600 million.

At 60% adoption:

£360 million annual payment volume.

If the platform's illustrative gross payment economics equated to 0.10% of processed volume, that would represent:

£360,000 of gross annual payment revenue.

This is only an illustration. Actual payment economics vary significantly by provider, card mix, merchant pricing, costs, risk, services and commercial agreement.

But it demonstrates why established software companies should calculate payment volume before accepting a generic referral agreement.

Wholesale Pricing vs Revenue Share

One of the biggest commercial decisions is whether the platform receives a share of provider revenue or has greater influence over the merchant price.

Revenue share

The provider sets or controls merchant pricing and pays the software business an agreed share.

This can be operationally simpler.

Wholesale or buy-rate model

The platform may have greater ability to determine the commercial proposition above an agreed underlying cost.

This can create more upside but may introduce more responsibility around:

• pricing governance;
• sales;
• customer communication;
• margin management;
• fee changes;
• commercial-card pricing;
• international cards; and
• support.

A platform should model both scenarios against realistic payment volumes and merchant adoption.

Find Your New Processor

Who Controls Merchant Pricing?

Do not assume that “white-label” automatically means the software company can charge merchants whatever it wants.

Ask:

• Who sets the headline card rate?
• Who controls minimum pricing?
• Can the platform vary pricing by merchant?
• Can enterprise customers receive bespoke pricing?
• Who pays scheme and interchange changes?
• How are international and commercial cards priced?
• Can terminal fees be marked up?
• Can gateway charges be marked up?
• Can the provider alter wholesale pricing?
• How much notice must be given?
• Who communicates pricing changes to merchants?

These details often matter more commercially than the branding itself.

Who Supports the Merchant?

Support can become one of the biggest hidden costs of a white-label payment proposition.

If a merchant sees the payment service as part of your software, they will often contact you when something goes wrong.

Typical queries include:

• Why was my application declined?
• Why do you need another document?
• Why was this transaction declined?
• Where is my settlement?
• Why is my payout delayed?
• How do I refund a customer?
• Why has my account been restricted?
• How do I respond to a chargeback?
• My terminal has stopped working – what do I do?
• Why has my pricing changed?

The commercial agreement should make clear who handles:

• first-line support;
• technical support;
• merchant underwriting;
• risk escalations;
• settlement queries;
• terminal support;
• chargebacks;
• complaints;
• fraud;
• billing;
• incidents; and
• out-of-hours support.

White-Label Card Terminals

For vertical software serving physical businesses, card-present payments may be just as important as ecommerce.

A white-label proposition may potentially include:

• integrated payment terminals;
• terminal ordering;
• terminal estate management;
• device configuration;
• software-to-terminal communication;
• refund workflows;
• terminal branding;
• multi-site deployment; and
• central transaction reporting.

The software business should establish whether the provider supports both online and in-person payments through one platform or requires separate technical and commercial relationships.

Recurring Payments and Subscriptions

Recurring payments are critical for many vertical SaaS portfolios.

Examples include merchants operating:

• memberships;
• subscriptions;
• health plans;
• maintenance plans;
• recurring bookings;
• regular deliveries; and
• software-driven billing models.

The white-label partner should be assessed on:

• tokenisation;
• stored credentials;
• subscription APIs;
• failed-payment retries;
• card updating;
• customer cancellation;
• refunds;
• payment-status webhooks;
• Direct Debit where required; and
• migration capabilities.

Who Owns the Payment Tokens?

This question can become extremely important several years after launch.

If thousands of merchants have recurring customers using stored payment credentials, the platform may become deeply dependent on the original provider.

Before signing the agreement, establish:

• where payment credentials are vaulted;
• who controls the tokens;
• whether token export is contractually permitted;
• whether tokens can be transferred securely to another PCI-compliant provider;
• what assistance the provider will give during migration;
• what happens to recurring schedules;
• whether merchants must consent to migration; and
• whether end customers may need to re-authorise payments.

Read our detailed guide to moving stored cards, tokens and recurring payments.

Merchant Portability Matters Too

Token portability is only part of the exit problem.

If the software company has onboarded 5,000 merchants to one payment partner, ask:

• Who owns the merchant records?
• Can merchant information be reused during migration?
• Will every merchant need to complete a new application?
• Can KYC data be transferred?
• Will underwriting need to be completed again?
• Can merchants keep existing merchant IDs?
• Will terminals need replacing?
• What happens to unsettled transactions?
• What happens to chargebacks after termination?
• Can the platform communicate directly with those merchants?

A successful white-label proposition can create significant payment revenue, but it can also create significant provider lock-in.

Exclusivity Should Be Examined Carefully

Some payment partnerships may contain:

• payment exclusivity;
• minimum volumes;
• minimum merchant numbers;
• country restrictions;
• vertical restrictions;
• preferred-provider obligations; or
• commercial targets.

These should be considered against the platform's longer-term strategy.

A software business may eventually need a second provider because of:

• merchant risk appetite;
• international expansion;
• different currencies;
• new payment methods;
• local acquiring;
• larger enterprise merchants;
• higher-risk merchants;
• resilience;
• different terminal requirements; or
• commercial negotiation.

Should a White-Label Platform Support Multiple Acquirers?

Larger software businesses may want to avoid tying their entire payments proposition to one acquiring route.

A more flexible architecture can potentially allow different merchants or transaction flows to use different acquirers.

This can help where a platform serves:

• multiple industries;
• different risk categories;
• enterprise and SME merchants;
• multiple countries;
• different transaction values; or
• businesses with existing acquiring relationships.

Platforms considering this architecture should also read our guide to acquirer-agnostic payment gateways.

White-Label Payments for Marketplaces

Marketplaces create additional payment requirements because one customer transaction may involve multiple participants.

The platform may need:

• seller onboarding;
• split payments;
• platform commissions;
• seller payouts;
• reserve management;
• refund allocation;
• chargeback allocation;
• multi-currency support;
• reconciliation; and
• ongoing seller verification.

A marketplace should not assume that a conventional white-label gateway provides the infrastructure required to manage marketplace fund flows.

Read our Split Payment Gateways guide.

White-Label Payments Are Not the Same as Merchant of Record

This distinction is also important.

A white-label payment proposition generally relates to providing payment infrastructure or merchant-payment services under the platform's brand.

A Merchant of Record model involves a different commercial and legal structure where another entity becomes the seller of record for the transaction and takes on responsibilities associated with that role.

White-labelling a payment gateway does not automatically make the software company or payment provider the Merchant of Record.

Read our guide to Merchant of Record models.

Does a SaaS Platform Need FCA Authorisation for White-Label Payments?

Not simply because payment functionality is white-labelled.

The regulatory position depends on what the platform actually does.

The FCA states that businesses may be providing payment services where, for example, they receive customer money before passing it to a seller.

The FCA also distinguishes between regulated acquiring/payment activities and merely technical services.

This means the regulatory analysis needs to consider:

• who receives or controls funds;
• who contracts with merchants;
• who provides acquiring services;
• whether the platform acts on behalf of a payment institution;
• whether an agency structure applies;
• who handles settlement;
• what activities the platform actually performs; and
• whether any exclusion is genuinely available.

A platform should obtain specialist regulatory advice before assuming that a particular commercial structure falls outside payment-services regulation.

Be Especially Careful Where the Platform Receives Customer Money

A software company should pay particular attention if its proposed model involves funds being received into an account in the platform's name before being passed to another business.

The FCA specifically highlights marketplaces and booking businesses as examples where payment-services regulation may become relevant depending on how customer money flows.

The payment architecture should therefore be designed alongside the contractual and regulatory structure rather than being treated solely as an API project.

PCI DSS and White-Label Payments

White-labelling does not remove PCI DSS considerations.

The platform should establish:

• whether raw card data touches its systems;
• whether hosted fields are used;
• whether payment pages are provider-hosted;
• whether tokens replace card details;
• how card-present payments are secured;
• which systems can affect payment security;
• the platform's PCI scope; and
• the merchant's PCI responsibilities.

A deeply branded user interface can still be designed so that sensitive card details are handled by specialist payment infrastructure rather than directly by the SaaS platform.

See our PCI DSS Compliance Guide for general information.

Reporting and Reconciliation

Payment reporting is an important part of the software value proposition.

A platform may want to provide merchants with:

• transaction history;
• authorisation status;
• refunds;
• chargebacks;
• fees;
• settlement;
• payout status;
• terminal transactions;
• online transactions;
• subscription status;
• failed payments; and
• multi-location reporting.

The provider should therefore be evaluated not only on the transaction API but also on:

• reporting APIs;
• webhooks;
• settlement files;
• merchant-level reporting;
• platform-level reporting;
• fee reporting;
• dispute reporting; and
• reconciliation data.

Webhooks and Account Status Are Critical

Payment events continue after the initial transaction.

A platform may need to receive events when:

• a merchant is approved;
• more KYC information is required;
• a merchant becomes restricted;
• a payment succeeds;
• a payment fails;
• a refund completes;
• a chargeback is received;
• a payout is sent;
• settlement fails;
• a subscription payment fails; or
• merchant-account status changes.

Good white-label payment architecture should therefore be designed around the merchant and transaction lifecycle rather than just the checkout.

International Expansion

A payment partner that works well for a UK-only SaaS platform may not necessarily be suitable when the platform expands.

Check:

• merchant onboarding countries;
• acquiring coverage;
• settlement currencies;
• processing currencies;
• local payment methods;
• card-present availability;
• merchant verification requirements;
• local entities;
• cross-border fees;
• FX;
• data requirements; and
• support coverage.

International capability should be verified against the platform's actual expansion plan rather than relying on a provider's headline number of supported countries.

What Should Be Included in a White-Label Payment Provider Comparison?

What Information Should a SaaS Platform Prepare?

Before comparing white-label payment providers, prepare a commercial and technical profile covering:

• software product;
• industries served;
• number of existing business customers;
• number of new customers added each month;
• customer countries;
• estimated annual payment volume;
• average monthly volume per merchant;
• average transaction value;
• maximum transaction value;
• card-present percentage;
• online-payment percentage;
• recurring-payment percentage;
• payment methods;
• terminal requirements;
• marketplace or split-payment requirements;
• existing payment integrations;
• current payment adoption;
• expected future adoption;
• current merchant pricing;
• development resources;
• merchant-support capability;
• desired level of branding;
• international plans;
• preferred commercial model;
• target launch date; and
• long-term payment strategy.

This information enables providers to price and structure the opportunity against genuine commercial volume rather than an abstract software integration.

When White-Label Payments May Not Be the Right Model

White-labelling is not automatically the best answer.

A lighter integration may be more appropriate where:

• the software has a small merchant base;
• payment volumes are limited;
• customers already have strong payment-provider relationships;
• the platform does not want to provide payment support;
• merchant risk profiles are extremely diverse;
• the platform lacks development resources;
• payments are not strategically important;
• the commercial upside is too small; or
• provider lock-in would create more risk than value.

In these cases, an integrated or referral model may achieve most of the benefits without introducing unnecessary complexity.

When White-Label Payments Become Strategically Valuable

The case becomes stronger where a software business has:

• a substantial existing merchant portfolio;
• meaningful annual payment volume;
• high customer retention;
• a repeatable vertical proposition;
• payments naturally occurring inside its software;
• strong merchant adoption potential;
• capacity to support the product;
• a clear payment monetisation strategy; and
• the scale to negotiate commercial terms.

At that point, payments can move from being an external integration to becoming part of the software company's core commercial proposition.

Migrating From an Existing Payment Integration

Software companies already integrated with a payment provider should map the existing estate before moving to a white-label model.

This can include:

• active merchants;
• existing merchant contracts;
• payment tokens;
• recurring transactions;
• terminals;
• transaction history;
• refunds;
• open chargebacks;
• settlement;
• merchant pricing;
• APIs;
• webhooks;
• reporting;
• customer communications; and
• support arrangements.

Do not switch off the original infrastructure until the merchant and payment migration has been tested thoroughly.

Merchant Advice Service View

White-label payments should not begin as a branding exercise.

For an established SaaS or software business, the real opportunity is to decide whether payments should become part of the company's product, customer relationship and revenue model.

The platform should start by understanding:

its merchant portfolio + payment volume + merchant acceptance requirements + desired commercial model + operational appetite.

Then determine:

which elements of payments it actually wants to control.

That may be only the user experience.

Or it may include onboarding, merchant pricing, support, reporting and a substantial share of payment economics.

The mistake is assuming that the provider offering the most white-label branding automatically offers the best platform-payment proposition.

The better partnership is the one that fits:

your merchants + your software + your commercial model + your risk appetite + your long-term payment strategy.

How Merchant Advice Service Helps SaaS and Software Platforms

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

We work with businesses exploring more complex payment arrangements, including software companies and platforms considering how payments should sit inside their proposition.

This can include:

• white-label payment processing;
• embedded payments;
• integrated payments;
• ISV payment partnerships;
• merchant acquiring;
• payment gateways;
• payment terminals;
• merchant onboarding;
• managed PayFac models;
• recurring payments;
• split payments;
• multi-acquirer requirements;
• tokenisation;
• payment-provider migration;
• commercial payment models; and
• international payment requirements.

For established platforms, the starting point is usually to understand the current merchant portfolio and payment volume before comparing provider technology and commercials.

Final provider availability, underwriting, regulation, contracts, technical approval and commercial terms remain subject to the relevant organisations.

Find Your New Processor

Related Merchant Advice Service Guides

• How ISVs Can Benefit From Integrated Payments
• Embedded Payments for SaaS & Platforms
• Payment Facilitators: What They Are and When to Use One
• Split Payment Gateways for Marketplaces & Platforms
• Payment API Integration
• Acquirer-Agnostic Payment Gateways
• Moving Stored Cards, Tokens & Recurring Payments
• Payment Provider Risk Appetite
• Merchant of Record Explained
• PCI DSS Compliance Guide
• Payments for Healthcare Software Platforms

Sources and Reference Organisations

• Financial Conduct Authority – determining whether a business may be providing payment services
• FCA Handbook PERG 15 – payment services perimeter guidance, including acquiring, Payment Facilitators and technical services
• Financial Conduct Authority – Payment Services Regulations and e-money framework
• Stripe Connect – platform payments, merchant onboarding, embedded components and monetisation
• Stripe – merchant onboarding and verification options
• Adyen for Platforms – platform-payment infrastructure
• Adyen – hosted and API-only onboarding
• NMI – white-label payment-gateway infrastructure
• PCI Security Standards Council – PCI DSS

Editorial disclosure: Payment companies and products are referenced to illustrate different platform-payment, onboarding and white-label models. Inclusion does not constitute a recommendation or ranking. Branding capability, merchant acceptance, technical functionality, pricing, commercial models and geographic coverage can change and should be verified directly before making a decision.

This guide provides general payment-processing information and does not constitute legal, regulatory, financial, tax or compliance advice. Businesses considering Payment Facilitator, agent, marketplace or other structures involving greater responsibility for merchants or customer funds should obtain appropriate specialist advice.