How ISVs Can Benefit from Integrated Payments

For an Independent Software Vendor — ISV — payments can be much more than another integration.

Once customers already use your software to run an important part of their business, payment processing can become part of the product itself.

That can potentially allow an ISV to:

• simplify payment setup for its customers;
• connect payments directly with existing workflows;
• improve transaction and reconciliation data;
• reduce the need for customers to source payment providers independently;
• strengthen the overall software proposition;
• create recurring payment-related revenue;
• increase customer retention;
• support new markets and payment methods; and
• develop a deeper strategic relationship with its payment partners.

But there are several ways to do it.

An ISV might simply integrate with a payment gateway.

It might negotiate a commercial revenue-share agreement.

It might offer a more deeply embedded or white-label payment proposition.

Or, at the more complex end of the market, it might explore a Payment Facilitator or managed PayFac model.

The important decision is not simply whether to integrate payments. It is how much of the payment experience, merchant relationship, economics and operational responsibility the software business actually wants to own.

Quick Summary

• This guide is primarily for established ISVs, vertical SaaS companies and software platforms with an existing portfolio of business customers that accept payments.
• ISV integrated payments connect payment acceptance with the software product used by the ISV's customers.
• Integrated payments, embedded payments, white-label processing and Payment Facilitator models are related but are not identical.
• An ISV does not have to become a Payment Facilitator to generate commercial value from payments.
• Payment-provider partnerships can potentially include referral fees, revenue share or other commercial arrangements.
• The payment provider's merchant acceptance and risk appetite should match the ISV's actual customer portfolio.
• Merchant onboarding is as important as the payment API. A technically strong integration has limited value if many customers cannot be approved.
• The ISV should understand who owns KYC/KYB, underwriting, merchant support, chargebacks, settlement and ongoing risk monitoring.
• The software platform should decide how much control it wants over pricing, branding, onboarding and the merchant relationship.
• Payment integrations should be designed for refunds, recurring payments, reconciliation and failures as well as successful transactions.
• Payment data portability matters because a deeply integrated provider can become difficult to replace later.
• If an ISV or platform itself begins providing regulated payment services, UK regulatory requirements may become relevant.
• Simply integrating another firm's payment service does not automatically mean the software company itself is a regulated PSP.
• PCI DSS and payment-software security responsibilities depend on the technical architecture and the role the ISV performs.
• The right payment model should support the software company's customer base today without unnecessarily restricting how the platform evolves later.

Find Your New Processor

Who Is This Integrated Payments 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.

Typical examples include software serving:

• retailers;
• restaurants and hospitality businesses;
• hotels;
• healthcare practices;
• fitness businesses;
• professional services;
• property businesses;
• booking-led businesses;
• field-service companies;
• education providers;
• membership businesses;
• marketplaces; and
• other specialist verticals.

If you are a merchant looking to connect payments with the software you already use — such as EPOS, ERP, CRM, booking or accounting software — read our Integrated Payments Solutions UK guide.

If you are a software company or platform exploring how payments can become part of your own proposition, including payment monetisation and broader platform-payment models, read our Embedded Payments for SaaS and Platforms guide.

For wider strategic guidance on payment architecture, provider selection and payment infrastructure, explore the Merchant Advice Service Payments Strategy Library.

What Are Integrated Payments for an ISV?

For an ISV, integrated payments usually means connecting payment functionality directly into the software used by the ISV's customers.

Instead of the customer operating:

software → separate terminal/gateway → separate reporting → manual reconciliation

the experience can become:

software → payment request → payment provider → payment result → software workflow.

Depending on the product, that payment could relate to:

• a retail sale;
• a restaurant bill;
• a booking;
• an invoice;
• a subscription;
• a membership;
• a deposit;
• a customer account;
• a marketplace transaction; or
• another vertical-specific workflow.

MAS View

For an ISV, the real value of integrated payments is not that the software can take a card payment. It is that the payment becomes part of the workflow the customer already depends on.

Integrated Payments vs Embedded Payments for ISVs

The terms overlap, but it is useful to separate them.

A software company can therefore have a very good integrated-payment product without necessarily operating a deeply embedded payment model.

For the wider platform models, see our Embedded Payments guide.

What Are the Main ISV Payment Models?

There is no single structure every software company needs to follow.

1. Payment Referral Model

The ISV refers customers to a payment provider.

The customer establishes its payment relationship with the provider, while the software supplies the technical integration.

The ISV may receive a commercial referral payment depending on the agreement.

This can be relatively simple operationally because the payment provider retains most responsibility for:

• merchant onboarding;
• underwriting;
• payment processing;
• settlement;
• risk monitoring; and
• merchant-account management.

2. Integrated Payments Partnership

The ISV develops a deeper strategic relationship with one or more payment providers.

This may include:

• integrated merchant onboarding;
• preferred commercial pricing;
• revenue sharing;
• joint support processes;
• integrated reporting;
• co-marketing;
• payment APIs or SDKs; and
• a defined roadmap between the software and payment businesses.

3. Embedded Payments Model

Payments become a more substantial part of the software proposition.

The platform may control more of:

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

4. White-Label Merchant Processing

With a white-label model, more of the payment experience can appear under the software company's own brand.

Exactly what can be white-labelled — and which organisation retains responsibility for underwriting, contracts, settlement and regulated activities — depends on the provider and model.

Read our White-Label Merchant Processing guide.

5. PayFac or Managed PayFac Model

At the deeper end of the market, software companies may explore a Payment Facilitator structure or models commonly described as managed PayFac or PayFac-as-a-Service.

These can provide significantly more control over merchant onboarding and the payment proposition, but they also introduce additional operational, risk, acquiring and potentially regulatory considerations.

Read our Payment Facilitators: How the Model Works for Merchants and Platforms guide.

How Much of the Payment Stack Should an ISV Own?

This is one of the most useful strategic questions an ISV can ask.

Greater control can create greater commercial opportunity.

It can also create greater:

• technical responsibility;
• support responsibility;
• risk exposure;
• compliance requirements;
• implementation complexity; and
• dependency on the underlying payment architecture.

MAS View

ISVs should not take ownership of parts of the payment stack simply because a provider makes it possible. They should own the parts that create strategic value for the software business.

How Can an ISV Make Money From Payments?

Payment partnerships can potentially create recurring revenue for software companies.

The exact commercial model varies considerably.

Possible structures can include:

• one-off referral fees;
• revenue share linked to payment processing;
• commercial margin arrangements;
• platform fees;
• premium payment functionality;
• subscription tiers containing payment features;
• implementation fees;
• payment-related software fees; or
• other commercial partnership models.

The ISV should understand exactly:

• what triggers revenue;
• which transactions qualify;
• how revenue is calculated;
• when it is paid;
• how refunds and chargebacks affect it;
• whether international transactions are treated differently;
• whether the commercial model changes with volume;
• what happens if the merchant leaves; and
• whether the economics remain competitive for the merchant.

Payment Revenue Should Not Be Assessed in Isolation

Consider a software platform that generates payment revenue but forces its customers onto commercially uncompetitive processing.

That may increase short-term payment income while making the software proposition weaker.

A sustainable model needs to work for:

the ISV + the payment partner + the merchant.

The merchant still needs appropriate:

• pricing;
• settlement;
• support;
• payment performance;
• risk acceptance;
• hardware or gateway functionality;
• international capability; and
• contract terms.

For a detailed explanation of the payment-cost stack, read our Payment Gateway Fees UK 2026 guide.

Does Integrated Payment Revenue Increase an ISV's Valuation?

Recurring payment-related revenue can make payments an important part of a software company's commercial model.

However, it would be misleading to say that integrating payments automatically increases the valuation of an ISV.

Business valuation can depend on many factors including:

• quality and predictability of revenue;
• customer retention;
• gross margins;
• growth;
• customer concentration;
• payment-partner dependency;
• contract durability;
• regulatory exposure;
• risk exposure; and
• the transferability of the payment arrangement.

Payment revenue should therefore be assessed as part of the wider SaaS economics rather than treated as an automatic valuation multiple.

The Most Important ISV Metric May Be Customer Payment Volume

Before approaching payment partners, an ISV should understand the payment opportunity across its existing portfolio.

Useful information includes:

• number of software customers;
• number already accepting payments;
• average payment turnover per customer;
• total estimated portfolio payment volume;
• transaction count;
• average transaction value;
• card-present vs online mix;
• recurring-payment volume;
• countries;
• currencies;
• merchant sectors;
• Merchant Category Codes where known;
• refund levels;
• chargeback profile; and
• expected customer growth.

Illustrative Example

An ISV has:

1,000 active customers.

If 600 of those customers process an average:

£40,000 per month

through the software, the potential portfolio payment volume is:

£24 million per month

or:

£288 million per year.

This is an illustrative MAS calculation only.

But it demonstrates why an ISV should evaluate payment-provider negotiations at portfolio level, not simply as one software integration.

MAS View

An ISV integrating payments is not bringing one merchant to a payment provider. It may be bringing an entire merchant distribution channel.

Why Merchant Acceptance Matters as Much as the API

A provider can have excellent developer documentation and still be the wrong payment partner.

Imagine an ISV serving:

• travel businesses;
• supplement retailers;
• regulated businesses;
• high-ticket merchants;
• subscription businesses;
• international merchants; or
• other sectors requiring specialist underwriting.

If the proposed provider has limited appetite for those merchants, a technically excellent integration may have low customer adoption.

Before integrating, establish:

• which merchant categories are accepted;
• which are prohibited;
• which require additional underwriting;
• geographic restrictions;
• transaction-value limits;
• expected onboarding times;
• reserve policies;
• chargeback tolerance;
• international acceptance; and
• what happens when a merchant falls outside standard risk appetite.

What Should an ISV Know About Merchant Onboarding?

Integrated merchant onboarding can be just as important as integrated payment acceptance.

The customer journey might be:

software account → payments application → KYB/KYC → underwriting → merchant activation → payments enabled.

An ISV should understand:

• who collects merchant information;
• which information is required;
• whether onboarding is hosted or embedded;
• which identity/business checks are performed;
• who makes underwriting decisions;
• when manual review occurs;
• how requests for additional information are communicated;
• who tells a merchant it has been declined;
• how quickly approved merchants can go live; and
• what happens when an existing customer is not acceptable to the provider.

Should an ISV Use One Payment Provider?

There are clear benefits to having a primary payment partner.

These can include:

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

But there are also risks.

A single provider may not support:

• every merchant sector;
• every country;
• every currency;
• every payment method;
• every transaction size;
• every acquiring requirement; or
• every future business model.

The ISV also becomes more dependent on one payment infrastructure provider.

Should an ISV Integrate More Than One PSP or Acquirer?

For larger platforms, possibly.

A multi-provider strategy can potentially support:

• different risk appetites;
• different markets;
• commercial negotiation;
• payment resilience;
• international acquiring;
• specialist merchant categories;
• different payment methods; and
• reduced dependency on one provider.

But every additional integration creates more:

• development;
• testing;
• support;
• reporting;
• reconciliation;
• merchant routing logic; and
• commercial management.

Platforms considering multiple PSPs or acquirers should also read our Payment Orchestration UK guide.

How Should ISVs Choose an Integrated Payments Partner?

We would divide provider selection into eight areas.

1. Merchant Fit

• Does the provider support the ISV's sectors?
• Can it accept the expected transaction values?
• Can it support the customer geographies?
• Does its underwriting model fit the portfolio?

2. Technical Fit

• APIs;
• SDKs;
• webhooks;
• card-present integrations;
• tokenisation;
• developer environments;
• documentation;
• versioning;
• testing tools.

For the wider technical design questions, read our Payment API Integration guide.

3. Merchant Onboarding

• embedded onboarding;
• hosted onboarding;
• KYB/KYC;
• underwriting;
• manual review;
• activation;
• declines;
• ongoing monitoring.

4. Commercial Model

• merchant pricing;
• ISV revenue share;
• minimum commitments;
• gateway fees;
• platform fees;
• international charges;
• FX;
• contract term;
• commercial-review mechanisms.

5. Merchant Experience

• branding;
• onboarding UX;
• payment UX;
• reporting;
• settlement visibility;
• refunds;
• merchant support.

6. Risk & Compliance

• merchant acceptance;
• fraud controls;
• chargebacks;
• reserves;
• KYB/KYC;
• PCI responsibilities;
• regulated responsibilities.

7. Support

• Who supports the merchant?
• Who supports the API?
• Who handles outages?
• What is the escalation process?
• Does the ISV receive specialist partner support?

8. Future Fit

• new countries;
• new payment methods;
• card-present payments;
• subscriptions;
• marketplaces;
• split payments;
• additional acquirers;
• white labelling;
• future PayFac strategy.

What Payment Features Should an ISV Consider?

The answer should be driven by the customers the software already serves.

Potential requirements include:

• ecommerce payments;
• integrated card machines;
• Tap to Pay;
• payment links;
• virtual terminals;
• recurring payments;
• card-on-file;
• network tokenisation;
• digital wallets;
• international currencies;
• local payment methods;
• pre-authorisation;
• delayed capture;
• refunds;
• split payments;
• marketplace payouts; and
• multi-acquirer processing.

Should ISVs Build Payments Into Their Existing Workflow?

Yes — that is usually where the value of the integration appears.

Consider a booking-software company.

A weak payment integration might simply add:

Pay Now.

A deeper integration could potentially support:

booking created → deposit calculated → payment collected → booking confirmed → token stored → balance scheduled → payment reconciled.

Or for an ERP:

invoice created → payment request sent → customer pays → accounts receivable updated → settlement reconciled.

The software company should therefore design around the customer's workflow rather than merely inserting a checkout component.

Why Reconciliation Matters for ISVs

Payments create several different events:

• authorisation;
• capture;
• refund;
• chargeback;
• provider fee;
• settlement;
• payout.

The software should decide which of those events matter to its customers and how they map into the underlying business records.

For example:

customer → order → payment → settlement.

Strong transaction identifiers and reporting can make reconciliation significantly easier.

Read our Payment Reconciliation guide.

What Happens When an Integrated Payment Fails?

ISVs should design for failure as well as success.

Possible scenarios include:

• payment declined;
• payment succeeds but software does not receive confirmation;
• duplicate request;
• webhook delayed;
• customer closes the browser;
• PSP outage;
• merchant account restricted;
• terminal loses connectivity;
• refund fails;
• settlement differs from expected payment totals.

The software needs clear rules for:

• transaction status;
• retry logic;
• idempotency;
• manual intervention;
• customer messaging;
• reconciliation;
• support escalation.

MAS View

An ISV payment integration is only as good as the workflow it provides when the payment does not behave exactly as expected.

Who Owns Merchant Support?

This should be agreed commercially before the payment product launches.

Possible models include:

Provider-Led Support

The merchant contacts the payment provider directly.

ISV First-Line Support

The merchant contacts the software company, which escalates payment issues where required.

Joint Support

Responsibilities are split according to the type of issue.

For example:

The exact structure varies, but the merchant should not be left to discover ownership during an incident.

Should an ISV White-Label Payments?

White labelling may be attractive where the software company wants greater control over:

• branding;
• merchant experience;
• customer relationship;
• pricing presentation;
• reporting;
• support; and
• payment monetisation.

But the term white label can describe very different models.

Ask:

• Whose legal name appears in the merchant agreement?
• Who is the actual payment provider?
• Who performs underwriting?
• Who settles funds?
• Whose brand appears during onboarding?
• Who sets merchant pricing?
• Who handles support?
• What compliance responsibilities sit with the ISV?
• Can the merchant relationship be moved if the ISV changes provider?

Read our White-Label Merchant Processing guide.

Does an ISV Need to Become a Payment Facilitator?

No.

A software company does not need to become a traditional PayFac simply because it wants to offer integrated or embedded payments.

Alternatives can include:

• referral partnerships;
• integrated PSP partnerships;
• embedded-payment infrastructure;
• white-label models;
• managed PayFac structures; and
• PayFac-as-a-Service arrangements.

The more useful question is:

What payment responsibilities does the ISV actually want to control?

For a full explanation of the operating model, see our Payment Facilitator guide.

When Does UK Payments Regulation Become Relevant to an ISV?

An ISV integrating with another payment provider does not automatically become a regulated payment institution.

However, the regulatory analysis can change depending on what the platform actually does.

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

The FCA also specifically warns that marketplaces, booking businesses and other businesses bringing buyers and sellers together may potentially be providing payment services where they receive customer money before passing it to another party.

An ISV should therefore obtain specialist regulatory advice where the proposed model involves the platform itself:

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

FCA — Payment Services Regulations and Electronic Money Regulations

FCA — Consider Whether You Provide Payment Services

MAS View

Technical integration and regulated payment provision are different questions. The closer a software platform moves towards controlling the movement of money, the more important the regulatory structure becomes.

What Are the PCI DSS Considerations for ISVs?

PCI responsibilities depend on the technical architecture and the role the software company performs.

An ISV should establish:

• whether cardholder data enters its software;
• whether payment pages are provider-hosted;
• whether tokenisation is used;
• whether the platform stores payment credentials;
• whether the ISV has access to the merchant's cardholder-data environment;
• whether the ISV provides ongoing payment-related services; and
• which PCI standards or validation requirements apply to the particular implementation.

PCI SSC also maintains its Secure Software Standard specifically for software vendors and developers producing software that supports or facilitates payment transactions.

PCI SSC — Secure Software Standard

PCI requirements should be confirmed with the relevant payment provider, acquirer, QSA or appropriately qualified PCI professional.

What Should an ISV Test Before Launching Integrated Payments?

The test plan should extend well beyond:

“Can we make a payment?”

Depending on the product, test:

• merchant onboarding;
• successful payments;
• declines;
• 3D Secure;
• payment cancellation;
• duplicate requests;
• refunds;
• partial refunds;
• stored credentials;
• recurring payments;
• failed recurring payments;
• webhooks;
• delayed responses;
• terminal connectivity;
• merchant suspension;
• settlement;
• reporting;
• reconciliation;
• chargebacks;
• user permissions;
• customer support;
• provider support; and
• outage/fallback processes.

How Should an ISV Roll Payments Out to Existing Customers?

A full portfolio launch is not always the best first step.

A controlled pilot can help establish:

• onboarding conversion;
• merchant approval rates;
• time to activation;
• technical reliability;
• merchant support requirements;
• payment volumes;
• commercial economics;
• merchant feedback; and
• unexpected sector-specific issues.

One useful sequence is:

partner selection → integration → internal testing → pilot merchants → measure → refine → broader rollout.

What ISV Payment Metrics Should Be Tracked?

Merchant Adoption

• customers invited;
• customers applying;
• customers approved;
• customers activated;
• active processing merchants.

Onboarding

• application completion rate;
• approval rate;
• manual-review rate;
• decline rate;
• time to go live.

Payments

• payment volume;
• transactions;
• average transaction value;
• authorisation rate;
• refunds;
• chargebacks.

Commercial

• payment revenue;
• revenue per active merchant;
• payment gross margin where applicable;
• provider costs;
• support cost;
• integration cost.

Customer

• payment adoption by software segment;
• customer retention;
• support tickets;
• merchant satisfaction;
• reasons customers do not adopt the integrated payment option.

What Happens if the ISV Wants to Change Payment Provider Later?

This needs to be considered before signing the first payment partnership.

Ask:

• Who owns the merchant relationship?
• Can merchants move to another provider?
• Who owns payment tokens?
• Can stored credentials be migrated?
• Can the API abstraction be reused?
• What transaction data can be exported?
• How are historic refunds handled?
• How are ongoing chargebacks handled?
• What happens to merchant contracts?
• What happens to ISV revenue after termination?
• Are there exclusivity provisions?
• Are there minimum terms?

For businesses dealing with stored credentials, see our Changing Payment Gateway: Stored Cards, Tokens & Recurring Payments guide.

MAS View

A payment partnership can become deeply embedded in a software company's product. Exit architecture should therefore be considered at the same time as integration architecture.

Should an ISV Build a Payment Abstraction Layer?

For some larger platforms, separating internal business logic from provider-specific payment logic can make future development easier.

For example, the platform's internal system may maintain its own references for:

• customers;
• merchants;
• payments;
• refunds;
• subscriptions;
• payment methods.

Those internal references can then be mapped to provider-specific objects.

This can potentially make it easier to:

• add another provider;
• change provider;
• route merchants differently;
• support different markets; or
• maintain a consistent product experience.

Whether that additional architecture is justified depends on the size and technical strategy of the platform.

The MAS ISV Payments Partnership Test

Merchant Advice Service would evaluate an ISV payment opportunity across seven areas.

1. Portfolio

Who are the merchants, how much do they process and what sectors do they operate in?

2. Product

Where does payment functionality genuinely improve the software workflow?

3. Provider Fit

Can the payment partner accept and support the ISV's actual merchant portfolio?

4. Commercial Model

How will merchant pricing and ISV payment revenue work?

5. Ownership

Who owns onboarding, underwriting, support, settlement, risk and merchant relationships?

6. Architecture

How are payments integrated, secured, reconciled and supported?

7. Portability

Can the software business evolve or change payment partners without rebuilding the entire product?

MAS View

Portfolio → Product → Provider Fit → Commercial → Ownership → Architecture → Portability.

The best payment partnership is not the one that generates the highest theoretical revenue per transaction. It is the one that creates a sustainable payment product for the ISV and its merchants.

Find Your New Processor

How Merchant Advice Service Helps ISVs and Software Platforms

Merchant Advice Service helps ISVs, SaaS companies and software platforms understand payment-provider and partnership options.

A review can consider:

• merchant portfolio;
• payment volumes;
• merchant sectors;
• current payment integrations;
• gateway and acquiring options;
• merchant onboarding;
• embedded payments;
• white-label processing;
• PayFac and managed PayFac models;
• commercial revenue-share structures;
• international acquiring;
• recurring payments;
• tokenisation;
• split payments;
• marketplaces;
• payment orchestration;
• provider risk appetite;
• implementation requirements; and
• future payment strategy.

MAS does not act as an acquiring bank, processor or regulatory adviser.

Our role is to help software businesses understand the payment model they require and identify providers or specialist payment partners that may fit that model.

For broader payment models, read our Embedded Payments guide, White-Label Merchant Processing guide and Payment Facilitator guide.

For wider strategic guidance, explore the Payments Strategy Library or The Payments Directory®.

Sources & Further Reading

Financial Conduct Authority — Payment Services Regulations

The FCA explains the scope of regulated payment services in the UK and the circumstances in which businesses providing payment services may require authorisation or registration.

FCA — Payment Services Regulations 2017 & Electronic Money Regulations

Financial Conduct Authority — Platforms and Payment Services

The FCA specifically advises marketplaces, booking businesses and other businesses bringing buyers and sellers together to consider whether their activities may amount to providing payment services, particularly where they receive customer funds before passing them to another party.

FCA — Consider If You Provide Payment Services

PCI Security Standards Council — Secure Software

PCI SSC's Secure Software Standard provides security requirements for software vendors and developers whose software supports or facilitates payment transactions.

PCI SSC — Secure Software Standard

PCI Security Standards Council — PCI DSS

PCI DSS v4.0.1 is the current PCI Data Security Standard and defines security requirements for environments involving payment account data.

PCI SSC — PCI DSS

Related Merchant Advice Service Guidance

• Integrated Payments Solutions UK — Merchant Guide
• Embedded Payments for SaaS & Platforms
• White-Label Merchant Processing
• Payment Facilitators: PayFac Models
• Payment API Integration
• Payment Gateway Fees UK 2026
• Payment Reconciliation
• Subscription Payment Processing
• Moving Stored Cards, Tokens & Recurring Payments
• Payment Orchestration UK
• Split Payment Gateways
• Marketplace Payment Gateways
• Compare UK Payment Providers
• Payments Strategy Library
• The Payments Directory®

Editorial & Commercial Disclosure

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

MAS may receive commission, referral fees or other commercial remuneration from some payment providers or partners where a business chooses to proceed following an introduction. This does not determine the factual information, payment-model analysis or provider-selection principles included in this guide.

Integrated-payment, embedded-payment, white-label and PayFac models vary significantly between providers. The terminology used by individual payment companies should not be assumed to describe identical legal, commercial or acquiring structures.

Payment-related revenue is not guaranteed and depends on the commercial agreement between the ISV and payment partner, merchant adoption, payment volumes and other contractual factors.

Integrating payment technology does not automatically make an ISV a regulated payment-service provider. However, platforms undertaking activities that fall within the UK payments regulatory perimeter may require FCA authorisation, registration or another appropriate regulatory structure. Businesses should obtain specialist regulatory advice where required.

PCI DSS and payment-software security requirements depend on the ISV's technical architecture, access to payment account data and role within the payment environment. Formal PCI guidance should be obtained from the relevant acquirer, payment provider, QSA or appropriately qualified professional where necessary.

Merchant acceptance remains subject to payment-provider and acquiring-partner underwriting and risk appetite.

Payment-provider functionality, APIs, commercial terms, regulatory requirements and technical integrations can change.

Merchant Advice Service does not guarantee merchant approval, payment revenue, technical compatibility, implementation timescales, regulatory status or commercial outcomes.

Payments, PCI and regulatory information last checked: 28 August 2026

This guide provides general payments information and should not be treated as legal, regulatory, accounting, investment, valuation, cybersecurity or formal PCI compliance advice.