Switching Card Machine Provider: How to Change Without Disrupting Payments
Published - 27 August 2026
Revised - 27 August 2026


Libby James is the founder and Managing Director of Merchant Advice Service. Since 2016, she has worked directly with businesses and payment providers across merchant accounts, card processing, payment gateways and complex provider requirements.
Libby specialises in high-risk, declined and harder-to-place merchants, as well as businesses requiring specialist payment methods, integrations or international support. She writes and reviews Merchant Advice Service content, drawing on practical experience gained from real merchant enquiries and provider relationships.
Switching card machine provider can reduce payment costs, improve service, replace outdated terminals or give a business access to better integrations and reporting.
But for an established merchant, changing provider is rarely as simple as:
cancel old card machine → plug in new card machine.
The payment environment may also include:
A poorly planned switch can create unnecessary downtime, duplicate contracts, broken EPOS integrations or difficulty processing refunds after migration.
A well-planned switch should do the opposite.
The safest approach is to build, configure and test the replacement payment route before withdrawing the existing one.
This guide explains how UK businesses can change card machine or merchant-services provider while reducing disruption to payments.
Yes.
Businesses can change card-machine and merchant-services provider, subject to their contractual obligations and the practical requirements of the migration.
The main question is not whether switching is possible.
It is:
what else has to change with the card machine?
For a simple standalone terminal, the answer may be relatively little.
For an integrated multi-site retailer or hospitality group, the change might affect:
The larger the merchant, the less useful it becomes to think of switching as a card-machine replacement. It is a payment migration.
Common reasons include:
Sometimes switching is driven primarily by price.
In other cases, the payment infrastructure has simply been outgrown.
A provider review is particularly useful:
Starting the review before the existing agreement expires gives the business time to negotiate, compare, test and migrate properly.
Before looking at replacement providers, map the existing payment environment.
Record:
This becomes the baseline against which any replacement provider should be assessed.
Possibly.
One of the first things to establish is whether the merchant has separate agreements for:
These contracts may:
That can create a problem if the acquiring agreement can be changed but the business remains committed to incompatible terminal hardware or software.
See our Merchant Services Contract Renewal guide.
The Payment Systems Regulator identified lengthy POS-terminal agreements as one factor that could discourage merchants from shopping around and changing card-acquiring provider.
As a result, Specific Direction 16 limits the initial term of qualifying POS-terminal contracts for relevant merchants and specified providers.
Within scope:
Read PSR Specific Direction 16.
The direction has a defined scope, so businesses should still check their own contractual position rather than assuming every terminal agreement in the UK operates identically.
The Payment Systems Regulator has also introduced measures intended to make card-acquiring services easier for merchants to understand and compare.
For providers and merchants within the relevant scope, this includes:
The summary information can help identify:
Read the PSR's current card-acquiring comparison guidance.
Do not compare the new provider against the transaction rate you remember agreeing several years ago.
Use actual statements.
Review several months of:
Then establish the true current cost.
See our Card Machine Costs UK 2026 guide.
A quotation showing:
0.75%
is not automatically cheaper than one showing:
0.85%.
The merchant needs to understand:
Where possible, model the replacement provider's quotation against the merchant's actual historic card data.
See our Card Machine Transaction Fees guide.
Suppose a business processes:
£750,000 per month.
A difference of:
0.10 percentage points
is equivalent to:
£750 per month
or:
£9,000 per year.
At that level of card turnover, small pricing differences can be considerably more important than a modest difference in terminal rental.
This is an illustrative MAS calculation and does not represent expected provider savings.
The higher the card turnover, the more important it becomes to compare the payment economics rather than the card-machine rental.
Do not begin with a list of providers.
Begin with the business requirements.
For example:
This stops the comparison becoming:
old machine vs new machine.
Instead, it becomes:
old payment environment vs proposed payment environment.
This is one of the most important migration checks.
If the business uses an integrated EPOS system, establish:
Do not sign the new card-acquiring agreement and investigate EPOS compatibility afterwards.
See our Integrated Card Machines & EPOS Compatibility guide.
Often, yes — provided the EPOS platform supports the proposed payment provider or integration.
Possible outcomes include:
This may allow a relatively straightforward terminal and acquiring migration.
The business may need new software, configuration or licences.
Larger or bespoke merchants may need development and testing before migration.
The merchant may have to:
Sometimes, but never assume so.
Whether existing terminal hardware can be reused depends on:
A terminal being technically capable of accepting Visa and Mastercard does not mean another payment provider can automatically use it.
If the current machines are rented, they may also need to be returned.
Even where technically possible, ask whether it makes sense.
Consider:
A provider migration can be a useful point to remove obsolete hardware from the estate.
Often, yes.
A Merchant ID — MID — identifies the merchant within the acquiring/payment setup.
A new acquiring relationship will commonly involve new merchant IDs.
For a simple single-site merchant this may be straightforward.
For a larger business, the MID structure needs more thought.
The merchant may require:
The new MID structure should support reporting and reconciliation rather than simply replicate the old setup without review.
Potentially.
The new provider may have different:
Before go-live, finance teams should know:
A payment migration may look successful from the till while creating problems in finance.
For example:
customer pays → transaction approved → terminal works.
But:
Payment migration testing should therefore include reconciliation, not just authorisation.
Changing card processor does not automatically change the merchant's PCI DSS scope.
However, a migration can alter the payment architecture.
For example, the business may move between:
Those changes can affect PCI DSS responsibilities and validation.
See our Changing Card Processor & PCI DSS guide.
No.
PCI SSC makes clear that outsourcing payment processing to a third party does not remove all merchant responsibility.
Depending on the environment, merchants may still need to:
For the wider requirements, see our PCI DSS Compliance Guide for UK Businesses.
A migration can involve significant movement of payment hardware.
The merchant should control:
See our Card Machine Security & PCI DSS guide.
This is the central migration principle.
Where contracts and provider arrangements allow, the preferred sequence is:
approve → configure → integrate → install → test → go live → verify → retire old route.
Not:
cancel → lose service → install → discover problems.
The old provider should not disappear from the payment journey before the new provider has proved it can replace it.
There is no universal timeframe.
A straightforward merchant changing a handful of standalone terminals could have a very different migration from a national retailer replacing hundreds of integrated devices.
Timing depends on:
The commercial team should not dictate a go-live date before the technical requirements are understood.
A successful test transaction is necessary.
It is not sufficient.
Depending on the business, the test plan should include:
A £1 test proves that the system can authorise £1. It does not prove that your business is ready to migrate its payment volume.
For multi-site or operationally complex businesses, a pilot can be extremely useful.
For example:
one store → several stores → regional rollout → full estate.
A pilot can expose:
Those are easier to solve across five terminals than five hundred.
Multi-site migrations should normally be approached as a rollout programme.
Consider:
A retailer with 100 sites should not necessarily migrate all 100 at 9am on the same Monday simply because the new contract starts that day.
A parallel run means maintaining the existing payment route while the replacement environment is being introduced and validated.
Where commercially and technically possible, this can reduce migration risk.
However, it can also create:
The overlap should therefore be planned and time-limited.
The migration plan should answer:
“What happens if the new card machines do not work?”
Potential options can include:
The correct fallback depends on what has failed.
See our Card Machine Connectivity, Outages & Backup Payment Options guide.
Potentially.
Tap to Pay can provide another card-present acceptance option on supported smartphones.
It can be useful for:
However, the service still needs to be:
See our Tap to Pay UK guide.
This is one of the most important practical questions.
A customer may return after go-live seeking a refund for a transaction processed through the old provider.
Businesses should establish:
Do not close all access to the old provider simply because new transactions have moved.
Chargebacks and disputes relating to historic transactions can continue after the new provider goes live.
The merchant may still need:
Historic payment responsibilities do not disappear on the migration date.
Businesses should retain records in accordance with their legal, accounting, contractual, PCI and operational requirements.
From a payment-migration perspective, ensure necessary historic records are available before old portal access is removed.
This may include:
A card-machine migration may be part of a wider provider change.
If the existing provider also handles:
those channels should be assessed separately.
Changing card-present acquiring does not necessarily require changing the online gateway.
Equally, changing the entire provider relationship may involve token migration and considerably more technical work.
See our guide to moving stored cards, tokens and recurring payments.
In some payment architectures, yes.
This depends on whether the gateway supports multiple acquiring connections and whether the relevant providers and integrations are compatible.
Businesses with complex omnichannel requirements should establish:
Yes.
Payment-provider migrations can fail operationally even when the technology works.
Staff may need to understand:
Training should happen before go-live rather than during the first customer transaction.
Finance teams should receive:
IT or technical teams may need:
Operations should understand:
Do not judge success only from whether customers can tap their cards.
A successful migration should demonstrate that:
The first statements from the new provider should be checked against the agreed quotation.
Review:
An attractive proposal is useful only if the live billing matches it.
The migration is not complete when the new terminal goes live. It is complete when the new payment arrangement has proved technically, operationally and commercially that it works.
The merchant ends the old service before the replacement environment is operational.
A lower transaction rate is selected without checking integration, support or total cost.
The new provider is signed before the EPOS integration is verified.
The merchant owns the hardware but discovers the new provider cannot support it.
The old portal is closed before historic transactions can be properly managed.
Transactions work, but finance cannot reconcile the money arriving in the bank.
A problem that could have been found during a small pilot affects the entire estate.
The business discovers its contingency plan during the outage rather than before it.
The technology changes but the operational process does not.
The merchant assumes the contracted rates have been applied correctly without verifying them.
Before changing provider, confirm:
Merchant Advice Service would break the switch into six stages.
Understand the current payment arrangement, contracts, costs, hardware and integrations.
Define what the replacement payment environment needs to do.
Assess suitable providers using actual payment data and technical requirements.
Complete onboarding, integrations, MID setup, settlement configuration and terminal deployment.
Test transactions, refunds, EPOS, reporting, settlement, support and fallback routes.
Move live volume only when the replacement environment has demonstrated that it can support the business.
Audit → Design → Compare → Build → Prove → Cut Over.
That is a payment migration. Simply replacing the terminal is not.
Merchant Advice Service helps established businesses compare payment-provider options and plan the commercial side of a provider change.
When reviewing a switch, we may consider:
The merchant contracts directly with the selected payment provider.
MAS can remain involved through the comparison and provider-introduction process and, where appropriate, during implementation and go-live.
Explore potential providers through The Payments Directory® or read How Merchant Advice Service Works.
The PSR identified difficulty comparing prices, indefinite card-acquiring arrangements and lengthy POS-terminal contracts as factors that could restrict merchants' willingness or ability to search and switch provider.
PSR — Card-Acquiring Market Review Final Report
The PSR introduced summary information, quotation tools, trigger messages and POS-terminal contract measures designed to make it easier for merchants to understand, compare and switch card-acquiring services.
PSR — Card-Acquiring Market Remedies
Specific Direction 16 restricts the initial length of relevant POS-terminal contracts for qualifying merchants and specified card-acquiring providers.
The PSR's current implementation guidance sets out the information directed card-acquiring providers should present to help relevant merchants understand and compare their existing arrangements.
PSR — Card-Acquiring Comparison Guidance
PCI SSC confirms that outsourcing payment processing does not automatically remove all PCI DSS responsibilities from a merchant.
PCI SSC — Merchant Responsibilities When Outsourcing Payments
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, provider-selection framework or migration principles included in this guide.
There is no universal best payment provider or single migration process suitable for every merchant.
Switching requirements depend on factors including existing contracts, terminal ownership, acquiring arrangements, EPOS integration, payment architecture, PCI DSS scope, card turnover and individual provider requirements.
Specific Direction 16 applies only to relevant contracts, qualifying merchants and specified payment-service providers within its defined scope. Businesses should review their own contractual position before terminating an agreement.
Changing payment provider does not automatically change PCI DSS scope. Changes to terminals, integrations, P2PE solutions, payment applications, networks or other architecture can affect a merchant's PCI DSS responsibilities.
Formal legal, contractual and PCI DSS advice should be obtained from appropriately qualified advisers, the merchant's acquirer, payment provider or QSA where required.
Merchant-account acceptance remains subject to provider underwriting.
Provider pricing, integrations, hardware, contracts and technical requirements can change.
Merchant Advice Service does not guarantee pricing, provider acceptance, implementation timescales or technical compatibility.
Regulatory and payments information last checked: 27 August 2026
Article last reviewed: August 2026
This guide provides general payments information and should not be treated as legal, regulatory, technical, financial or formal PCI compliance advice.
Written or reviewed by Libby James, founder of Merchant Advice Service and specialist in merchant payments and complex provider requirements.