How ISVs Can Benefit from Integrated Payments

Integrated Payments for ISVs: How Software Companies Can Monetise Payments

For an Independent Software Vendor (ISV), payments can be much more than an integration requested by customers.

They can become part of the commercial model of the software business itself.

If your customers already use your software to manage bookings, memberships, subscriptions, orders, reservations or other business activity, many of those customers may also be accepting payments through providers they arranged independently.

That creates an important strategic question:

Why should all of that payment value sit outside your platform?

An established ISV may be able to integrate payment processing into its software, simplify the customer experience and participate commercially in payment volume already generated across its customer portfolio.

The opportunity can be particularly significant for vertical software businesses with hundreds or thousands of existing customers.

But building an integrated-payments proposition involves considerably more than choosing an API.

An ISV needs to understand:

• how much payment volume exists across its customer base;

• how many customers might adopt the payment service;

• who sets customer pricing;

• how the software business earns from payments;

• who contracts with the individual merchant;

• how customers are onboarded and underwritten;

• what payment methods and integrations are required;

• how recurring payments and stored credentials are handled;

• who owns the payment relationship;

• what happens if the payment partner changes;

• what regulatory responsibilities sit with each party; and

• how the payment proposition will scale as the software business grows.

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

For a broader explanation of the different platform-payment models, read our Embedded Payments for SaaS and Platforms guide, or explore the Merchant Advice Service Payments Strategy Library.

---

Find Your New Processor

Quick Summary: Integrated Payments for ISVs

Integrated payments connect payment processing directly with an ISV's software, allowing its customers to manage payments alongside the other functions they already use within the platform.

For an established software vendor, this can create both a product opportunity and a commercial opportunity.

Depending on the payment-provider model, an ISV may potentially:

• offer payments directly through its software;

• simplify payment onboarding for customers;

• support online, recurring or in-person payments;

• improve reconciliation and reporting;

• create a more joined-up customer experience;

• white-label some or all of the payment proposition;

• earn referral or revenue-share income;

• negotiate underlying payment economics;

• set or influence customer payment pricing;

• retain margin generated from transaction volume; and

• create a recurring payment-revenue stream alongside software subscription income.

An ISV does not automatically need to become a Payment Facilitator (PayFac) to commercialise payments.

Current payment-platform models allow software businesses to choose different levels of control and responsibility. For example, Stripe currently supports platform models where Stripe sets merchant pricing and the platform may qualify for revenue share, as well as structures where the platform controls payment pricing. Adyen publicly offers SaaS platforms the ability to white-label payments and control transaction fees, while Worldpay for Platforms describes integrated-payment structures with merchant onboarding, margin control and payment monetisation.

The important question is therefore not simply:

“Which payment provider integrates with our software?”

It is:

“What payment business do we want to build around our software?”

---

What Is an ISV in Payments?

ISV stands for Independent Software Vendor.

An ISV develops software used by businesses to perform a particular function or manage part of their operations.

Examples include software for:

• hotel management;

• restaurant reservations;

• booking and scheduling;

• memberships;

• fitness and leisure;

• property management;

• professional services;

• education;

• events;

• ticketing;

• ecommerce;

• travel;

• healthcare;

• accounting;

• customer management; and

• specialist industry verticals.

Historically, the software relationship and payment relationship may have been separate.

The ISV supplied the software.

Its customer found a payment provider.

The two systems were connected.

Today, many software businesses are reconsidering that model.

If payments naturally form part of the workflow the software already manages, integrating them more deeply can allow the ISV to move from:

Software provider

to:

Software + payments platform

without necessarily becoming the underlying acquiring bank or regulated payment provider.

---

What Are Integrated Payments?

Integrated payments allow payment technology to communicate directly with business software.

Rather than taking a payment in one system and manually updating another, payment activity becomes connected to the underlying business process.

For example:

Booking software

Booking → deposit → payment → customer record → reconciliation

Membership software

Membership → recurring payment → failed-payment recovery → membership status

Hospitality software

Reservation → pre-authorisation → final payment → refund → reconciliation

Vertical SaaS

Customer transaction → payment → reporting → accounting

The first benefit is operational.

But there is a second opportunity for the ISV.

If the payment relationship is integrated more deeply into the platform, payments themselves can become part of the ISV's product proposition and revenue model.

---

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

There is no universally applied industry definition separating integrated and embedded payments.

Providers sometimes use the terms differently.

Broadly:

Payment model	Typical relationship with the software
External payment provider	Customer arranges payments separately from the software
Payment integration	Payment provider exchanges information with the software
Integrated payments	Payments form a more connected part of the software workflow
Embedded payments	Payments become a deeper part of the platform's product and customer experience
White-label payments	Some or all of the payment proposition appears under the software company's brand

The lines between these models can overlap.

An integrated-payment arrangement may become progressively more embedded as the ISV introduces onboarding, reporting, payment management and pricing into its own software.

The terminology is therefore less important than the actual structure.

An ISV should understand:

• who contracts with the merchant;

• who provides the regulated payment service;

• who sets the payment price;

• who performs merchant underwriting;

• who handles onboarding;

• who provides support;

• who carries payment risk;

• whose brand the customer sees;

• how the ISV earns money;

• who owns the customer relationship; and

• what happens if the payment partnership ends.

For more detail on these models, read our Embedded Payments for SaaS and Platforms guide.

---

Why Are ISVs Adding Payments to Their Software?

There are several reasons.

1. Additional Recurring Revenue

For many ISVs, this is the biggest commercial opportunity.

Software revenue is usually linked to:

• licences;

• subscriptions;

• users;

• locations; or

• modules.

Payment revenue introduces another potential income stream linked to transaction activity.

As customers grow and process more payments, payment revenue may grow alongside them.

---

2. Increased Product Value

Payments can make the software more useful.

A restaurant-booking platform that also handles deposits and payments is potentially more valuable to its customers than a platform requiring several disconnected systems.

The same principle applies to:

• memberships;

• appointments;

• bookings;

• property management;

• ecommerce;

• ticketing;

• subscriptions; and

• other transaction-led software.

---

3. A More Integrated Customer Experience

Customers may prefer to manage:

software + payments + reconciliation

through one platform rather than several providers.

That can reduce administrative friction and make payment data more useful within the wider software.

---

4. Greater Customer Retention

The deeper a product is embedded into the customer's core business workflow, the harder it can be to replace.

That should not be used to create artificial lock-in.

But a product that genuinely combines business operations and payments effectively can become more strategically important to the customer.

---

5. Better Payment Data

Integrated payments can provide the ISV with access to payment information relevant to the functionality of its platform, subject to the provider model, contracts, data permissions and applicable law.

This can potentially improve:

• reconciliation;

• transaction reporting;

• subscription management;

• payment status;

• business analytics; and

• customer experience.

---

Find Your New Processor

How Can an ISV Make Money From Payments?

There is no single ISV payment-revenue model.

The available structure depends on the payment provider, customer portfolio, payment volume, technology and level of responsibility the ISV wants to assume.

ISV Payment Models at a Glance

Model	How the ISV may earn	Who generally controls customer pricing?	ISV involvement
Integration only	Usually little or no direct payment revenue	Provider	Low
Referral	Referral fee or revenue share	Usually provider	Low
Integrated-payments partnership	Ongoing payment revenue or revenue share	Varies	Low–medium
Buy-rate / wholesale model	Margin between underlying payment economics and customer pricing	ISV may have greater control	Medium
White-label model	Margin, transaction fees or revenue share	Varies by structure	Medium–high
PayFac-style model	Greater control over processing economics	Platform may have substantial control	High

These are broad commercial models rather than fixed industry definitions.

Payment providers use different terminology, and the responsibilities attached to each structure vary.

---

What Is an ISV Revenue-Share Model?

In a revenue-share arrangement, the payment provider may retain control over merchant pricing and the core payment relationship while sharing an agreed portion of payment revenue with the ISV.

This can allow the software company to participate commercially without building a sophisticated payment-pricing operation.

Potential advantages include:

• relatively low operational involvement;

• provider-managed merchant pricing;

• provider-managed underwriting;

• simpler payment operations; and

• recurring revenue linked to payment activity.

The trade-off may be less control over:

• pricing;

• margin;

• branding;

• customer experience; and

• commercial strategy.

For some ISVs this is entirely appropriate.

For others, particularly platforms with large established customer portfolios, it may be worth exploring whether a more involved commercial model better reflects the value of the portfolio.

---

What Is a Buy-Rate or Wholesale Model for an ISV?

A buy-rate or wholesale model can give the software company greater control over payment economics.

Broadly, the ISV agrees underlying commercial terms with the payment provider.

Where the provider model permits it, the ISV can then offer payment processing to customers under a separate pricing structure and retain some of the difference.

Conceptually:

Customer processing price
– underlying payment economics
= potential ISV payment margin

The actual calculation may include:

• interchange;

• scheme fees;

• acquiring margin;

• gateway charges;

• transaction fees;

• international cards;

• payment methods;

• refunds;

• chargebacks;

• platform fees; and

• additional payment services.

Current payment providers demonstrate different versions of this concept.

Stripe Connect, for example, currently allows qualifying platforms either to use Stripe-set pricing with potential revenue share or to control pricing themselves. Stripe also supports platform mark-ups, additional transaction fees and IC+ network-cost passthrough in certain configurations.

Adyen publicly states that SaaS platforms can control transaction fees and monetise payments.

Worldpay for Platforms describes embedded-payment propositions with transparent pricing and control over margins.

The important point is not which provider offers the feature.

It is that ISVs now have more than one commercial route available.

---

The MAS ISV Payment Opportunity Test

Before approaching payment providers, an ISV should understand the size of the payment opportunity it could potentially bring.

The first calculation is straightforward.

Step 1: Estimate Addressable Payment Volume

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

Then:

Potential monthly payment volume × 12
= potential annual payment volume

---

Illustrative Example

Imagine a vertical software business has:

• 2,000 active business customers;

• 40% expected payment adoption; and

• £20,000 average monthly card volume per participating customer.

That gives:

2,000 × 40% × £20,000 = £16 million potential monthly payment volume

Or:

£192 million potential annual payment volume

This is not a forecast.

Not every customer will necessarily migrate.

Some merchants may not meet provider underwriting criteria.

Actual payment volume can vary significantly.

But it tells the ISV something commercially important:

the customer portfolio potentially represents substantial payment value.

That should be understood before commercial negotiations begin.

---

Step 2: Model the Potential Payment Revenue

The second stage is to model potential economics.

Broadly:

Potential annual payment volume
× potential net ISV margin
= indicative annual payment opportunity

An ISV can model several hypothetical margin scenarios rather than assuming one outcome.

For example, the business might consider what different net-margin assumptions would mean at:

• 20% customer adoption;

• 40% adoption;

• 60% adoption; and

• higher adoption over time.

The purpose is not to predict revenue precisely.

It is to understand how sensitive the business case is to adoption, payment volume and commercial terms.

MAS View

Do this modelling before asking payment providers for commercial terms.

If an ISV does not understand the potential annual payment volume it is bringing to a partnership, it is difficult to judge whether the proposed revenue share, buy rate or margin structure adequately reflects the value of that portfolio.

---

The MAS ISV Payments Readiness Test

Payment volume alone does not mean an ISV is ready to launch payments.

We would also assess five areas.

1. Portfolio

Does the ISV already have an established customer base?

Consider:

• number of active customers;

• customer retention;

• customer sectors;

• geographic concentration; and

• expected growth.

---

2. Payment Fit

Are payments naturally connected to what the software already does?

The strongest opportunities tend to exist where customers regularly need to accept payment as part of the workflow managed by the software.

---

3. Adoption

Why would customers use the ISV's payment proposition instead of their existing provider?

Potential reasons might include:

• simpler setup;

• better integration;

• improved reconciliation;

• competitive pricing;

• better payment functionality;

• fewer systems;

• better reporting; or

• functionality available only through the integrated proposition.

---

4. Technology

Can the software support:

• merchant onboarding;

• payment APIs;

• payment status;

• webhooks;

• reporting;

• tokenisation;

• refunds;

• reconciliation; and

• other required payment functions?

---

5. Commercial Strategy

Does the ISV know what it actually wants from payments?

For example:

• additional revenue;

• stronger retention;

• increased product value;

• international growth;

• an improved customer experience; or

• a combination of these.

A payment strategy should support the wider software strategy.

It should not exist simply because embedded payments are currently fashionable.

---

Do ISVs Need to Become Payment Facilitators?

No — not necessarily.

A traditional Payment Facilitator model can give a platform significant control over the payment proposition.

It can also introduce additional complexity and responsibility.

Depending on the model, modern payment providers can handle significant parts of:

• merchant onboarding;

• KYB/KYC;

• underwriting;

• acquiring;

• payment processing;

• settlement;

• fraud;

• compliance;

• chargebacks; and

• merchant monitoring.

The ISV can therefore potentially build a substantial integrated-payments proposition without itself operating a traditional PayFac model.

Different provider structures place different responsibilities on the platform.

The right question is therefore:

“How much control and responsibility does our software business actually want?”

rather than:

“How do we become a PayFac?”

---

Find Your New Processor

Are Integrated Payments Regulated for ISVs?

The regulatory position depends on what the ISV actually does within the payment flow.

Simply integrating payment technology into software does not automatically mean the software company itself is providing regulated payment services.

However, the structure matters.

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

The FCA specifically highlights that businesses such as:

• online marketplaces;

• businesses bringing sellers and customers together; and

• booking businesses

may need to consider whether they are providing payment services, particularly where they receive customer money before passing it to another party.

An ISV should therefore establish:

• who provides the regulated payment service;

• who contracts with the merchant;

• who receives or controls money;

• who performs merchant verification;

• who carries payment risk;

• who manages settlement;

• who handles chargebacks;

• who carries negative balances; and

• what activities the ISV itself performs.

Where the regulatory position is unclear, specialist legal or compliance advice should be obtained.

Merchant Advice Service does not provide legal or regulatory advice.

---

What Should an ISV Look for in a Payment Partner?

The payment API is important.

It is not enough.

An ISV should review the entire commercial, technical and operational structure.

---

Commercial Model

Understand:

• underlying payment economics;

• revenue-share structure;

• buy-rate options;

• who sets customer pricing;

• how ISV revenue is calculated;

• whether economics improve with scale;

• international card costs;

• additional transaction charges;

• platform fees; and

• minimum commitments.

---

Customer Ownership

Ask:

• Who contracts with each merchant?

• Who controls the payment relationship?

• Whose brand is visible?

• Who supports the merchant?

• What happens if the ISV changes payment partner?

• Can customer payment data be migrated?

• What rights does the ISV have over the portfolio?

This can become particularly important once the payment portfolio itself has significant commercial value.

---

Merchant Onboarding

Understand:

• how merchants apply;

• where onboarding occurs;

• who collects KYB/KYC information;

• who performs underwriting;

• how quickly merchants can go live;

• which sectors are supported;

• how referrals are handled;

• what happens when applications require manual review; and

• whether onboarding status can be returned into the software.

An attractive payment margin is commercially irrelevant if customers struggle to activate the product.

---

Payment Capability

An ISV should consider its future roadmap as well as today's requirements.

Does the payment partner support:

• online card payments;

• in-person payments;

• recurring billing;

• card-on-file;

• tokenisation;

• Apple Pay and Google Pay;

• alternative payment methods;

• multiple currencies;

• international processing;

• payment links;

• refunds;

• chargebacks;

• split payments;

• multiple locations; and

• future geographic expansion?

---

APIs and Integration

Technical teams should understand:

• API documentation;

• SDKs;

• webhooks;

• sandbox environments;

• onboarding APIs;

• reporting APIs;

• tokenisation;

• payment retries;

• refunds;

• chargebacks;

• authentication;

• versioning;

• uptime;

• support; and

• how changes to the API are communicated.

---

Reporting and Reconciliation

Integrated payments should ideally make software more useful.

Consider whether the ISV can provide customers with:

• payment status;

• transactions;

• settlement;

• refunds;

• chargebacks;

• fees;

• payout information;

• reconciliation; and

• other relevant payment reporting.

The ISV should also understand how its own payment revenue will be reported and reconciled.

---

Should an ISV Offer One Payment Provider or Several?

There is no universal answer.

A single embedded provider can simplify:

• development;

• onboarding;

• reporting;

• support; and

• commercial management.

But dependence on one provider can become important as an ISV grows.

Questions to consider include:

• Does one provider support every customer sector?

• Can it support every country?

• What happens if its risk appetite changes?

• Can specialist merchants be accommodated?

• Can an additional acquirer be added later?

• Would customers benefit from choice?

• How portable is the payment infrastructure?

For more complex payment environments, our guide to Acquirer-Agnostic Payment Gateways: Using One Gateway With Multiple Acquirers explains another approach to payment-provider flexibility.

---

How Should an ISV Migrate Existing Customers to Integrated Payments?

New customers and existing customers usually require different strategies.

New Customers

Integrated payments can be introduced during the normal software onboarding journey.

For example:

Create account → configure software → activate payments

This can make payment adoption relatively natural.

---

Existing Customers

Existing customers may already have:

• merchant accounts;

• gateway contracts;

• stored payment details;

• recurring payments;

• integrations;

• negotiated processing rates; and

• established payment workflows.

Moving them requires a clear commercial and operational reason.

The ISV should understand:

• who currently processes each customer's payments;

• whether contracts apply;

• whether customer credentials can move;

• whether recurring tokens need migrating;

• how pricing compares;

• what functionality improves;

• what development is required; and

• how disruption can be minimised.

Where stored payment details or recurring billing are involved, read our guide to changing payment gateways and moving stored cards, tokens and recurring payments.

---

Find Your New Processor

Integrated Payments for Booking Software

Booking platforms are a natural ISV payment use case.

The software already manages the point where:

customer chooses service → booking is made → money is due

Relevant sectors include:

• hotels;

• restaurants;

• events;

• leisure;

• travel;

• appointments;

• venues;

• activities; and

• professional services.

Payments may involve:

• deposits;

• full payment;

• stored cards;

• cancellations;

• refunds;

• recurring charges;

• card-present transactions; and

• customer-not-present transactions.

For more detail, see our Payment Providers for Booking Systems guide.

---

Integrated Payments for Membership and Subscription Software

Membership and subscription platforms may need payment functionality including:

• recurring billing;

• tokenisation;

• card updates;

• failed-payment recovery;

• retries;

• account status updates;

• upgrades;

• cancellations;

• international billing; and

• reporting.

When payments sit directly within the software, the customer's payment status can potentially become part of the wider membership workflow.

See our Subscription Payment Processing guide.

---

Integrated Payments for Hospitality Software

Hospitality technology can involve multiple payment environments at the same time.

For example:

• online bookings;

• card-present payments;

• deposits;

• bar and restaurant payments;

• stored cards;

• pre-authorisations;

• refunds;

• international guests;

• multiple properties; and

• complex reconciliation.

For ISVs serving hospitality customers, provider selection should therefore consider much more than a basic online-payment API.

Read our guide to Hotel Merchant Accounts and Payment Integration.

---

What Can Go Wrong With an ISV Payment Strategy?

The commercial opportunity can be significant, but there are several common mistakes.

Choosing the Provider Before Modelling the Opportunity

If you do not understand your customer portfolio's potential payment volume, it is difficult to negotiate effectively.

Choosing on API Quality Alone

The best technical demonstration does not automatically represent the best long-term commercial partnership.

Focusing Only on Revenue Share

Headline revenue share means little without understanding the underlying payment economics.

Ignoring Adoption

Revenue depends on customers actually activating the payment service.

Assuming Every Customer Will Be Accepted

Payment providers retain underwriting and risk criteria.

Ignoring Customer Portability

Understand what happens if the partnership needs to change in three years.

Building Only for Current Requirements

Future product plans may involve additional countries, payment methods or channels.

Accepting Too Much Operational Responsibility

Greater control can create additional risk, compliance and support responsibilities.

Making Payments Too Expensive for Customers

A payment proposition needs to create value for the ISV and remain commercially competitive for the businesses using the software.

---

What Information Should an ISV Gather Before Speaking to Payment Providers?

Before approaching potential payment partners, build a clear picture of the opportunity.

Customer Portfolio

Gather:

• number of active customers;

• customer sectors;

• customer locations;

• customer size;

• customer retention;

• current payment providers; and

• expected growth.

Payment Profile

Estimate:

• customer payment volume;

• total addressable volume;

• average transaction value;

• online vs in-person payments;

• recurring-payment volume;

• card mix;

• currencies;

• international transactions; and

• required payment methods.

Technology

Map:

• software architecture;

• APIs;

• onboarding;

• webhooks;

• payment status;

• reporting;

• tokenisation;

• refunds;

• recurring billing;

• customer portals; and

• available development resource.

Commercial Objectives

Decide whether the priority is:

• revenue share;

• payment margin;

• product differentiation;

• customer retention;

• white-label payments;

• better customer experience;

• international growth; or

• a combination.

Operational Requirements

Understand:

• merchant underwriting;

• customer support;

• fraud;

• compliance;

• chargebacks;

• settlement;

• reconciliation;

• disputes; and

• regulatory responsibilities.

A well-defined requirement creates a much more valuable payment-partner conversation than simply asking:

“Which payment providers integrate with our software?”

---

How Merchant Advice Service Works With ISVs

Merchant Advice Service approaches ISV payments as a commercial and payments-strategy decision first, and an integration project second.

1. Understand the Software Business

We start with:

• the software;

• customer base;

• sectors;

• geography;

• existing payment workflows; and

• future product strategy.

2. Assess the Payment Opportunity

We consider:

• customer numbers;

• potential adoption;

• estimated payment volume;

• payment requirements; and

• the potential commercial significance of the portfolio.

3. Define the Preferred Commercial Model

That might involve:

• referral revenue;

• revenue share;

• integrated payments;

• embedded payments;

• white-label payments;

• buy-rate economics; or

• another provider-supported structure.

The objective is not automatically to move the ISV towards the most complex model.

4. Work Through the Technical Requirements

These may include:

• APIs;

• onboarding;

• recurring billing;

• card-present payments;

• tokenisation;

• reporting;

• multi-currency;

• customer migration; and

• platform functionality.

5. Consider Provider Fit

Different payment providers have different:

• platform models;

• technical capabilities;

• customer-sector appetite;

• international coverage;

• underwriting;

• commercial structures; and

• levels of platform control.

Provider selection should follow the requirements — not determine them.

6. Make Relevant Introductions

Where appropriate, MAS can introduce the software business directly to payment providers whose capabilities and commercial models warrant further discussion.

The payment-processing contracts and relationships remain between the relevant businesses and the payment provider.

7. Remain Available

As the platform develops, payment requirements can change.

MAS remains available where further payment-strategy support is required.

You can also read How Merchant Advice Service Works, How MAS Researches and Compares Payment Providers and the wider Payments Strategy Library.

---

---

Find Your New Processor

Sources & Further Reading

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

Primary and Regulatory Sources

Financial Conduct Authority — Consider if You Provide Payment Services
The FCA specifically highlights online marketplaces, businesses bringing sellers and customers together and booking businesses as organisations that may need to consider whether their activities amount to providing payment services.

Financial Conduct Authority — Payment Services Regulations 2017 and Electronic Money Regulations 2011
FCA guidance on UK payment-services regulation, authorisation and registration.

Stripe Connect — Platform and Marketplace Payments
Stripe's current Connect proposition covers embedded onboarding, payment processing, platform monetisation and different levels of platform control.

Stripe Connect — Platform Pricing
Stripe currently documents models where Stripe can price connected merchants and qualifying platforms may earn revenue share, as well as models where platforms control payment pricing and collect fees.

Adyen for Platforms
Adyen's current platform proposition supports SaaS businesses embedding and white-labelling payments, onboarding users and controlling transaction pricing.

Worldpay for Platforms — Embedded Payments for Software Platforms
Worldpay currently describes embedded-payment products for software businesses with merchant onboarding, payment monetisation and control over margins.

---

Related Merchant Advice Service Guidance

• Payments Strategy Library

• Embedded Payments for SaaS and Platforms

• What Is White-Label Merchant Processing?

• Payment Providers for Booking Systems

• Subscription Payment Processing

• Split Payment Gateways for Marketplaces and Platforms

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

• Acquirer-Agnostic Payment Gateways

---

Editorial and Commercial Disclosure

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

MAS may receive commission or a referral fee from some payment providers where a business chooses to proceed following an introduction. This does not determine the factual information 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.

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

An integrated-payments proposition does not guarantee that every customer within an ISV's portfolio will be accepted by the underlying payment provider. Merchant eligibility, underwriting, sector restrictions, geography and provider risk appetite vary.

Integration with a payment provider does not by itself determine whether an ISV is providing regulated payment services. Businesses should establish the responsibilities of each party 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, commercial models, regulation, pricing and underwriting criteria can change. This guide provides general information and should not be treated as legal, regulatory or financial advice.