Integrated Payments Solutions UK: Connecting Payments With EPOS, ERP, CRM & Software

Integrated payments connect payment acceptance directly with the software a business already uses to sell, serve customers and manage its finances.

Instead of a payment happening in one system and the business manually updating another, payment information can move between the payment provider and systems such as:

• EPOS;
• ERP;
• CRM;
• booking software;
• property-management systems;
• accounting software;
• ecommerce platforms;
• subscription platforms;
• order-management systems; and
• bespoke business applications.

For an established business, that can make payments less of a standalone transaction and more of a connected operational process.

But integration also creates dependencies.

If the payment provider, software, connector, API, terminal or reporting flow does not work properly, the impact can extend beyond checkout into:

• orders;
• customer records;
• stock;
• bookings;
• invoices;
• refunds;
• settlement;
• finance reporting; and
• reconciliation.

The purpose of integrated payments is not simply to make the payment disappear into the software. It is to make the payment and the business process around it work as one controlled flow.

Quick Summary

• Integrated payments connect payment processing with another business system or workflow.
• Common integrations include EPOS, ERP, CRM, booking systems, ecommerce platforms, accounting software and bespoke applications.
• Integrated payments are not the same thing as embedded payments.
• They are also not the same thing as a payment API, although an API can be one way of creating an integration.
• EPOS-integrated card machines are one specific form of integrated payment.
• Integration can reduce manual entry and improve transaction-to-order matching, refunds, reporting and reconciliation.
• The payment provider does not necessarily need to supply the business software itself.
• A connector, plugin, middleware platform or API may sit between the payment provider and the operating system.
• Businesses should establish who owns and supports each part of the integration before signing a payment contract.
• Payment authorisation is only one part of the integration. Refunds, settlement, reconciliation, webhooks, errors and failed transactions also need to work.
• Changing payment provider can be more complex where the existing provider is deeply integrated into business systems.
• An integrated setup does not automatically reduce PCI DSS scope.
• For card-present environments, a PCI-listed P2PE solution can reduce applicable PCI DSS requirements when correctly implemented.
• Multi-site businesses should consider how integrations, reporting and support operate across the whole estate.
• The most suitable integrated payment provider is the one that fits the merchant's existing systems and future operating model, not simply the provider with the longest integration list.

Find Your New Processor

What Are Integrated Payments?

Integrated payments are payment-processing functions connected directly with another business system so that payment activity and operational data can move between the two without relying entirely on manual re-entry.

For example, imagine a retailer sells an item for £125.

Without integration:

staff enter £125 into EPOS → separately enter £125 into the terminal → customer pays → staff manually reconcile the two records later.

With an integrated terminal:

EPOS creates £125 sale → terminal receives £125 automatically → customer pays → payment result returns to EPOS → order/payment record is updated.

That is a relatively simple example.

Integrated payments can also connect much more complicated processes.

For example:

customer books → deposit collected → booking updated → token stored → balance collected later → payment posted to customer account → settlement reconciled in finance.

The payment is therefore connected to the wider business event.

MAS Definition

An integrated payment is a payment that exchanges useful information with the system responsible for the underlying customer or business workflow.

That distinction is useful because simply putting a payment button inside another screen does not necessarily mean the complete payment process is properly integrated.

What Systems Can Payments Integrate With?

Integrated Payments vs Embedded Payments: What Is the Difference?

The two terms are frequently used interchangeably, but it is useful to distinguish them.

There is overlap.

An embedded-payments platform obviously requires technical payment integration.

But the commercial objective can be different.

A retailer connecting card terminals to its EPOS system is using integrated payments.

A SaaS company adding payment acceptance to its software so that thousands of its customers can process transactions — potentially while the SaaS company earns payment revenue — is moving into embedded payments.

If you are a software company or platform looking to make payments part of your own product, read our Integrated Payments for ISVs guide and Embedded Payments guide.

MAS View

Integrated payments usually solve a merchant workflow. Embedded payments can become part of the software company's business model.

Are Integrated Payments the Same as a Payment API?

No.

An API — Application Programming Interface — is one technical method through which two systems can communicate.

An integrated payment solution might be created through:

• a direct API;
• a pre-built plugin;
• an EPOS connector;
• middleware;
• an SDK;
• a gateway integration;
• a payment application; or
• another provider-specific integration.

A business does not therefore need to build a custom API integration every time it wants integrated payments.

Equally, the existence of an API does not mean the provider is automatically integrated with the merchant's systems.

The merchant still needs to design and implement the required workflow.

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

Integrated Payments vs Payment Orchestration

These also solve different problems.

Integrated payments connect payment activity with the merchant's business systems.

Payment orchestration provides a control layer for managing payment routes, providers, acquirers or payment methods.

A merchant can use both.

For example:

ecommerce platform → internal payment integration → orchestration layer → PSP A / PSP B / Acquirer C.

The merchant's systems remain integrated with payments, while the orchestration layer determines how those payments are processed.

Read our Payment Orchestration UK guide.

How Do Integrated Card Machines Work?

Card-present integration typically connects the till or other business system to the payment terminal.

A simple flow might be:

EPOS → payment request → terminal → card authorisation → payment result → EPOS.

This can avoid staff manually keying the sale value into the terminal.

Depending on the implementation, integration may also support:

• refunds;
• voids;
• tips;
• split bills;
• transaction references;
• receipt information;
• store/MID information; and
• payment-status reporting.

This is an important area in its own right, so we cover the hardware and EPOS-specific requirements separately in our Integrated Card Machines & EPOS Compatibility guide.

How Do Integrated Online Payments Work?

Online integrations can be significantly more complex.

A typical ecommerce flow might involve:

checkout → payment provider → authentication → authorisation → order system → webhook → fulfilment → settlement → reconciliation.

Additional systems may also be involved, including:

• fraud platforms;
• subscription billing;
• customer accounts;
• CRM;
• warehouse management;
• ERP;
• tax software;
• finance systems; and
• customer-service tools.

The integration therefore needs to account for more than a successful payment response.

What Should an Integrated Payment Actually Automate?

The answer depends on the business.

Possible workflows include:

Payment Initiation

The operating system sends the correct value, currency and reference to the payment provider.

Payment Status

The business system learns whether a payment has:

• succeeded;
• failed;
• been declined;
• requires authentication;
• been cancelled; or
• remains pending.

Order or Booking Status

A successful payment can update the underlying transaction.

For example:

booking awaiting deposit → deposit paid → booking confirmed.

Refunds

The business may be able to initiate or record refunds without manually locating the transaction in another provider portal.

Customer Records

CRM or account records can reflect payment activity.

Reconciliation

Transaction references can be carried through to provider reporting and settlement data.

Reporting

Finance and operations teams can combine payment information with orders, customers, stores or invoices.

Why Is Reconciliation Such an Important Part of Integration?

A payment can process successfully while the wider operational process still fails.

For example:

customer pays £2,500 → payment authorised → order system records payment → £2,467.42 later reaches the bank.

Finance still needs to understand:

• which transactions formed that settlement;
• which fees were deducted;
• whether refunds were included;
• whether chargebacks were deducted;
• which business unit owns the transaction; and
• how the payment maps to the accounting system.

This is why payment integration should not stop at checkout.

Read our Payment Reconciliation guide.

MAS View

A payment integration is incomplete if the checkout is automated but finance still has to reconstruct every settlement manually.

What Are the Benefits of Integrated Payments?

Reduced Manual Entry

Amounts and references can move automatically between systems, reducing repetitive data entry.

Fewer Matching Errors

Transactions can carry common identifiers across the payment and operating systems.

Better Reconciliation

Payment data can be connected with orders, invoices, stores or customers.

Faster Operational Updates

A successful payment can automatically trigger the next stage of a workflow.

Improved Customer Experience

Customers may not need to wait while staff move between several systems or manually re-enter information.

Better Reporting

Payment performance can be analysed alongside business activity.

Scalability

A repeatable integration can make it easier to process higher transaction volumes or add further locations without increasing manual administration at the same rate.

Do Integrated Payments Reduce Processing Fees?

Not automatically.

Integration is primarily a technology and operational question.

The merchant may still pay:

• interchange;
• scheme fees;
• provider margin;
• gateway charges;
• authorisation charges;
• monthly fees;
• integration charges;
• software licences; and
• other payment-related costs.

A new integrated provider may produce a stronger commercial result, but that should be measured rather than assumed.

Read our Payment Gateway Fees UK 2026 guide for the wider payment-cost stack.

What Are the Main Types of Integrated Payment Setup?

Pre-Built Integration

The payment provider already has a supported connection with the merchant's software.

This can reduce development work, although the business should still establish exactly which features are supported.

Plugin or Connector

A third-party or provider-developed connector sits between the two systems.

Direct API Integration

The merchant develops directly against the payment provider's APIs.

This can offer greater control but creates more technical ownership.

Middleware

A separate integration layer connects business software to one or more payment services.

Integrated Payment Terminal

A card-present terminal exchanges payment information with EPOS or another operating system.

Orchestration Layer

A payment layer connects internal systems with several PSPs or acquirers and applies routing or provider logic.

What Is a Semi-Integrated Payment Setup?

In card-present payments, the term semi-integrated is often used for an architecture where the business software communicates with the payment terminal but sensitive card data is handled separately from the merchant's main application.

The exact technical architecture varies by provider.

This can be useful because the merchant system can still exchange operational information such as:

• transaction amount;
• payment status;
• transaction reference; and
• refund instructions

without necessarily needing to handle raw card data itself.

Merchants should confirm the actual data flow and PCI implications of the specific implementation rather than relying on the term “semi-integrated” alone.

How Do Integrated Payments Work With ERP Systems?

ERP integration can connect payments with wider finance and operational processes.

Depending on the business, a payment might update:

• an order;
• customer account;
• invoice;
• accounts receivable;
• inventory;
• shipment;
• cash position; or
• financial reporting.

For B2B and distribution businesses, the important question may be less about checkout and more about the complete:

order → invoice → collection → settlement → reconciliation

journey.

For more detail, see our Distribution ERP & Payment Operations guide and ERP & Accounts Receivable Automation guide.

How Do Integrated Payments Work With CRM?

CRM integration can connect payment events with customer activity.

For example:

invoice overdue → CRM workflow sends payment request → customer pays → payment status updates → account manager is notified.

Other use cases might include:

• membership renewal;
• customer deposits;
• payment plans;
• account status;
• service activation;
• sales follow-up; and
• collections workflows.

The integration should clearly establish which system is the authoritative record for:

• customer identity;
• payment status;
• invoice balance; and
• transaction history.

How Do Integrated Payments Work With Accounting Software?

Payment-accounting integrations can help connect payment information with invoices and bank reconciliation.

This may reduce:

• manual transaction matching;
• spreadsheet reconciliation;
• duplicate data entry; and
• time spent tracing settlements.

But the capabilities vary significantly.

Some integrations simply add a payment button to an invoice.

Others can provide much deeper transaction and settlement data.

If accounting integration is important, establish what actually synchronises rather than assuming that the word “integration” means full reconciliation.

For an example of this specific use case, see our Payment Providers That Integrate With Xero guide.

How Do Booking Systems Use Integrated Payments?

A booking business may need payments to follow the booking lifecycle rather than operate as a standalone checkout.

For example:

booking created → deposit taken → payment credential stored → cancellation rules applied → remaining balance collected → refund processed if required.

The requirements can be very different from ordinary ecommerce.

Important questions include:

• when the customer should pay;
• whether deposits are required;
• whether cards need to be stored;
• whether future balances will be collected automatically;
• how cancellation and refund rules work;
• whether several parties receive funds;
• how the booking is reconciled; and
• what happens when a payment fails.

Read our Payment Providers for Booking Systems guide.

What About Hotel and Hospitality Payment Integration?

Hospitality environments can combine several payment systems at once.

A hotel might use:

• online booking engine;
• PMS;
• front-desk terminals;
• restaurant EPOS;
• spa or leisure software;
• MOTO;
• stored credentials;
• deposits;
• pre-authorisations; and
• central finance reporting.

The payment strategy therefore needs to consider how these channels and systems interact rather than selecting each payment method independently.

See our Hotel Merchant Accounts & Payment Integration guide for the hospitality-specific requirements.

How Do Integrated Payments Work Across Multiple Locations?

Multi-site businesses need to consider integration at estate level.

For example:

• Does every location use the same EPOS?
• Does every store use the same terminal integration?
• How are MIDs structured?
• How does head office see all payments?
• Can local managers see only their own location?
• How are settlements mapped to stores?
• How are terminals deployed to new sites?
• Who supports integration failures?

A good architecture should make the next location easier to add rather than creating another bespoke integration project.

Read our Multi-Location Retail Merchant Services guide.

What Should You Check Before Choosing an Integrated Payment Provider?

1. Start With the Existing Software

Identify the systems the payment provider actually needs to connect with.

Do not begin with a shortlist of payment companies.

Begin with:

• EPOS;
• ERP;
• CRM;
• ecommerce;
• booking/PMS;
• subscription billing;
• accounting;
• internal applications; and
• reporting.

2. Establish the Required Payment Channels

Does the business need:

• online payments;
• card machines;
• MOTO;
• payment links;
• recurring payments;
• digital wallets;
• international payment methods; or
• several channels?

3. Map the Workflow

Do not simply ask whether an integration exists.

Ask what happens from the beginning of the transaction to the end.

For example:

order → payment → fulfilment → refund → settlement → reconciliation.

4. Check the Supported Features

Two providers can both claim to integrate with the same software while supporting different functionality.

Check:

• sales;
• refunds;
• partial refunds;
• pre-authorisation;
• capture;
• tips;
• recurring transactions;
• tokens;
• reporting;
• multi-location;
• currencies; and
• other merchant-specific requirements.

5. Establish Who Owns the Integration

The integration may be supplied by:

• the payment provider;
• software vendor;
• EPOS company;
• third-party connector;
• merchant development team; or
• systems integrator.

That affects both implementation and support.

Who Supports an Integrated Payment When Something Goes Wrong?

This question should be answered before go-live.

Otherwise the merchant can end up in the familiar situation:

“The software provider says it's a payment problem. The payment provider says it's a software problem.”

Agree:

• first-line support;
• technical ownership;
• incident escalation;
• support hours;
• responsibility for connectors;
• responsibility for network issues;
• responsibility for terminal hardware;
• responsibility for API failures; and
• how the two suppliers work together.

MAS View

The quality of an integration should be judged partly by what happens when it fails.

What Happens if the Integration Goes Down?

The answer depends on the architecture.

Possible scenarios include:

• the payment provider works but the business software does not;
• the software works but the payment provider is unavailable;
• the connector fails;
• the local internet connection fails;
• a webhook is delayed;
• the terminal loses communication with EPOS;
• the payment succeeds but the order does not update; or
• the payment fails after the business system assumes success.

The business should understand:

• which system controls transaction status;
• how failed messages are retried;
• what happens to duplicate messages;
• how staff identify a mismatch;
• whether a standalone payment route exists;
• how transactions are reconciled afterwards; and
• who resolves the incident.

What Is the Source of Truth for an Integrated Payment?

This is an important architectural question.

Imagine:

EPOS says:

PAYMENT COMPLETE.

But the payment provider says:

PAYMENT FAILED.

Which system wins?

Or:

The payment provider authorises a transaction, but the merchant's order-management system fails before recording the result.

The business needs rules for reconciling:

• payment-provider status;
• order status;
• customer status;
• fulfilment status; and
• finance status.

Integrated payments should reduce data fragmentation, not create several competing versions of the same transaction.

Why Payment References Matter

Good integration design should maintain identifiers that allow the business to connect:

customer → order → payment → refund → settlement.

This becomes particularly useful when:

• investigating customer queries;
• processing refunds;
• reconciling settlement;
• investigating chargebacks;
• switching provider;
• running two providers; or
• auditing transaction history.

Should Businesses Store Provider IDs as Their Main Internal IDs?

For bespoke environments, relying too heavily on provider-specific identifiers can make future migrations harder.

For example, your customer might be:

CUSTOMER-12865

internally.

The payment provider may give that customer another identifier.

The merchant can maintain a mapping between the two rather than designing its entire business around the provider's ID.

The same principle can apply to:

• payments;
• subscriptions;
• refunds;
• payment methods; and
• other provider objects.

This becomes particularly relevant for businesses considering multi-provider architectures or future migrations.

Does Integrated Payment Processing Affect PCI DSS?

Potentially.

PCI DSS applies to environments in which payment account data is stored, processed or transmitted.

The exact PCI scope of an integrated environment depends on how payment data moves through the systems.

Businesses should establish:

• whether raw card data enters merchant systems;
• whether tokenisation is used;
• whether payment pages are hosted by the provider;
• how card-present data is captured;
• whether a PCI-listed P2PE solution is used;
• which third parties are involved; and
• which systems remain within PCI scope.

PCI DSS v4.0.1 is the current version of PCI DSS.

Read PCI SSC's PCI DSS information.

Can P2PE Help With Integrated Card Payments?

Potentially.

PCI Point-to-Point Encryption — P2PE — is designed to protect payment account data from the point it is captured at the payment device through to the secure decryption environment.

PCI SSC states that merchants correctly using PCI-listed P2PE solutions have fewer applicable PCI DSS requirements.

That can be particularly useful in integrated card-present environments.

However:

• not every encrypted terminal setup is a PCI-listed P2PE solution;
• the exact solution should be checked against PCI SSC listings;
• the implementation needs to follow the relevant requirements; and
• P2PE does not remove PCI DSS entirely.

Read PCI SSC's P2PE guidance.

What About Integrated Recurring Payments?

Recurring payments add another layer because the payment relationship continues after the initial transaction.

The integrated system may need to manage:

• customer consent;
• stored credentials;
• payment tokens;
• billing schedules;
• payment retries;
• failed-payment workflows;
• customer updates;
• cancellations;
• refunds; and
• reporting.

The payment provider and subscription platform may therefore have different responsibilities.

Read our Subscription Payment Processing guide.

What About Integrated Marketplace Payments?

Marketplace payments involve additional considerations because the customer payment may ultimately relate to more than one party.

An integrated platform may need to connect:

• customer checkout;
• seller accounts;
• platform commission;
• seller onboarding;
• payment allocation;
• refunds;
• chargebacks;
• payouts; and
• reconciliation.

If one customer payment needs to be allocated between multiple recipients, see our Split Payment Gateways guide.

Should an ISV Use This Guide?

This article is primarily designed for merchants integrating payments with the software they use to operate their business.

If you are an Independent Software Vendor, SaaS provider or other platform integrating payments into the product you sell to customers, your questions are different.

You may also need to consider:

• merchant onboarding;
• payment partnerships;
• revenue sharing;
• white labelling;
• PayFac models;
• embedded payments;
• portfolio economics; and
• commercial ownership of the payment relationship.

See our Integrated Payments for ISVs guide.

How Hard Is It to Change an Integrated Payment Provider?

The deeper the integration, the more carefully the migration needs to be planned.

A merchant may need to change:

• API calls;
• terminal integrations;
• plugins;
• webhooks;
• payment IDs;
• tokens;
• refund flows;
• reporting;
• settlement reconciliation;
• fraud tools;
• 3D Secure;
• support processes; and
• internal documentation.

The migration should therefore begin by mapping everything the current payment provider does inside the operation.

For complex online integrations, read our Enterprise PSP Migration Guide.

For integrated physical terminals, read our Switching Card Machine Provider guide.

Should You Choose a Payment Provider Because It Already Integrates With Your Software?

Existing compatibility is valuable.

But it should not be the only selection criterion.

A provider could integrate perfectly while being weaker for:

• business-sector acceptance;
• commercial pricing;
• international cards;
• currencies;
• settlement;
• recurring payments;
• support;
• authorisation performance;
• fraud management;
• future markets; or
• other strategic requirements.

Integration fit should therefore form part of the wider provider comparison.

Read our Compare UK Payment Providers guide.

What Questions Should You Ask an Integrated Payment Provider?

• Do you already integrate with our software?
• Who developed that integration?
• Is it officially supported?
• Which versions of the software are supported?
• Which payment functions are supported?
• Who owns technical support?
• Are there additional integration fees?
• Does the integration support refunds?
• Does it support partial refunds?
• Does it support pre-authorisation and capture if required?
• How are transaction references passed between systems?
• How does settlement reconciliation work?
• What data can be exported?
• Are APIs available?
• Are webhooks available?
• What happens if the integration fails?
• Is standalone payment acceptance available as a fallback?
• How are software upgrades managed?
• How does the integration affect PCI DSS?
• Can the integration support multiple locations?
• Can it support several legal entities or MIDs?
• What happens if we change ERP, EPOS or CRM?
• What happens if we later change payment provider?

What Should Be Tested Before Go-Live?

Do not test only a successful sale.

A proper integration test can include:

• successful payment;
• declined payment;
• cancelled payment;
• duplicate request;
• refund;
• partial refund;
• void;
• pre-authorisation and capture where required;
• payment status updates;
• lost connectivity;
• delayed response;
• system restart;
• user permissions;
• reporting;
• settlement;
• reconciliation;
• multi-site operation;
• support escalation; and
• fallback payment route.

MAS View

A successful test payment proves that one payment worked. It does not prove that the integrated payment operation is ready.

The MAS Integrated Payments Test

Merchant Advice Service would assess an integrated payment requirement across six areas.

1. Workflow

What business event is the payment connected to?

For example:

sale, booking, invoice, subscription, order or customer account.

2. Payment Flow

How is the payment initiated, authorised, captured, refunded and settled?

3. Data

Which identifiers and payment statuses need to move between systems?

4. Ownership

Who owns the software, connector, API, payment account and technical support?

5. Resilience

What happens when one part of the integrated environment stops working?

6. Portability

How difficult would it be to change EPOS, ERP, payment provider or another core component later?

MAS View

Workflow → Payment Flow → Data → Ownership → Resilience → Portability.

The best integration is not simply the one that works on launch day. It is the one the business can operate, support and evolve after launch.

Find Your New Processor

How Merchant Advice Service Helps With Integrated Payments

Merchant Advice Service helps businesses compare payment providers where integration requirements form an important part of the decision.

Depending on the business, a review may consider:

• existing payment provider;
• EPOS;
• ERP;
• CRM;
• booking or property-management systems;
• accounting software;
• ecommerce platform;
• bespoke APIs;
• payment channels;
• transaction volume;
• card mix;
• recurring payments;
• tokenisation;
• MIDs;
• settlement;
• reconciliation;
• reporting;
• PCI considerations;
• commercial pricing;
• support;
• migration requirements; and
• future payment strategy.

MAS does not develop the integration itself.

Our role is to help the merchant understand the payment requirement and identify providers or payment architectures that may fit the technical and commercial environment.

The merchant contracts directly with the selected payment provider and should work with its own software vendors, developers and technical advisers where implementation work is required.

Businesses can explore providers through The Payments Directory®, read How Merchant Advice Service Works, or review How MAS Researches & Compares Payment Providers.

Sources & Further Reading

PCI Security Standards Council — PCI DSS

PCI DSS defines technical and operational security requirements designed to protect environments where payment account data is stored, processed or transmitted. PCI DSS v4.0.1 is the current version of the standard.

PCI SSC — PCI DSS

PCI Security Standards Council — Point-to-Point Encryption

PCI SSC states that P2PE protects payment account data from the point of capture to the secure point of decryption. Merchants correctly using PCI-listed P2PE solutions have fewer applicable PCI DSS requirements.

PCI SSC — Point-to-Point Encryption

PCI Security Standards Council — Payment Security Standards

PCI SSC maintains separate standards covering areas including PCI DSS, point-to-point encryption and secure payment software.

PCI SSC — Payment Security Standards

Related Merchant Advice Service Guidance

• Payment API Integration for Established Businesses
• Integrated Card Machines & EPOS Compatibility
• How ISVs Can Benefit from Integrated Payments
• Embedded Payments
• Find Embedded Payment Providers
• Payment Providers for Booking Systems
• Hotel Merchant Accounts & Payment Integration
• Distribution ERP & Payment Operations
• ERP & AR Automation Integration
• Payment Providers That Integrate With Xero
• Payment Reconciliation
• Subscription Payment Processing
• Payment Orchestration UK
• Split Payment Gateways
• Changing Payment Provider With a Custom API
• Switching Card Machine Provider
• Multi-Location Retail Merchant Services
• Payment Gateway Fees UK 2026
• Compare UK Payment Providers
• The Payments Directory®

Editorial & 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, integration framework or provider-selection principles included in this guide.

There is no universal integrated payment solution suitable for every business.

Integration requirements vary according to the merchant's software, payment channels, provider, operating model, transaction profile, technical architecture and business requirements.

References to integrated payments within this guide describe payment-processing functionality connected to wider merchant software and workflows. This is distinct from the broader commercial model of embedded payments, although the two areas can overlap.

An API is one possible integration method and should not be treated as synonymous with integrated payments.

Payment integrations can affect PCI DSS scope depending on how payment account data is stored, processed or transmitted. Businesses should confirm their individual PCI DSS responsibilities with their payment provider, acquirer, QSA or other appropriately qualified PCI professional where required.

Use of encryption does not automatically mean a solution is a PCI-listed P2PE solution. Merchants should confirm the exact solution against PCI SSC information where P2PE status is relevant.

Software compatibility, APIs, integrations and provider functionality can change. Businesses should verify current compatibility with both the payment provider and software supplier before entering into an agreement.

Merchant Advice Service does not develop or certify payment integrations and does not guarantee provider acceptance, technical compatibility, implementation timescales, payment performance or integration uptime.

Payment integration and PCI information last checked: 28 August 2026

This guide provides general payments information and should not be treated as legal, regulatory, cybersecurity, software-development or formal PCI compliance advice.