Changing Card Processor and PCI DSS: What Happens to Your Compliance?

Changing card processor does not automatically mean your PCI DSS obligations completely change.

But changing how your business takes payments can.

A merchant moving from one hosted payment page to another may retain a broadly similar payment architecture.

A business moving from a hosted checkout to a merchant-controlled API, embedded payment form or different card-data flow could create a materially different PCI DSS environment.

The most important question during a payment-provider migration is therefore not:

“Do we need to become PCI compliant again?”

It is:

“What changes in the way card data enters, moves through or can be affected by our systems when the new processor goes live?”

This guide explains what merchants should review when changing card processor, gateway or PSP under the current PCI DSS v4.0.1 framework.

For a broader explanation of PCI DSS itself, see our PCI DSS Compliance Guide for UK Businesses.

Quick Summary

• Changing processor does not automatically mean your PCI DSS scope changes.
• Your scope can change if the payment architecture changes.
• Moving from hosted checkout to direct API processing can materially increase merchant involvement with payment account data.
• Moving towards provider-hosted or tokenised payment components can potentially reduce the amount of card data handled by merchant systems.
• The correct SAQ depends on the new payment environment and whether all eligibility criteria are met.
• Do not assume you automatically need a completely different SAQ simply because the provider changes.
• Your acquirer or other PCI compliance-accepting entity should confirm the required validation route.
• PCI SSC clarified in June 2026 that relevant SAQ A ecommerce merchants can still require ASV external vulnerability scanning even where checkout redirects to a third-party provider or uses an embedded provider iframe.
• Stored cards and payment tokens should be reviewed before migration because ownership and portability vary by provider architecture.
• The old provider may need to remain operational for historic refunds, disputes and recurring transactions during migration.
• Temporary migration processes, test environments and logs should not accidentally expose cardholder data.

Find Your New Processor

Does Changing Card Processor Affect PCI Compliance?

Potentially, but not simply because the provider name changes.

The important factor is whether the payment environment changes.

Consider these two examples.

Example 1: Hosted Checkout to Hosted Checkout

A merchant currently redirects customers to a payment page fully controlled by Provider A.

It changes to a broadly similar hosted payment page supplied by Provider B.

The provider has changed, but the merchant's underlying interaction with card data may remain broadly similar.

The merchant still needs to confirm the new environment and validation requirements, but the move does not automatically create a much larger PCI scope.

Example 2: Hosted Checkout to Direct API

The merchant previously redirected customers to a PSP-hosted page.

It now designs its own checkout and sends payment account data through merchant-controlled infrastructure to Provider B's API.

That is a much more fundamental architecture change.

The merchant may now have systems, applications, servers or networks involved with cardholder data that were previously outside the payment-data flow.

MAS View

Changing processor is a commercial event. Changing card-data flow is the PCI event.

PCI DSS v4.0.1 Is the Current Standard

The current PCI Data Security Standard is PCI DSS v4.0.1.

PCI SSC states that v4.0.1 was a limited revision to PCI DSS v4.0 and did not introduce new or deleted requirements.

The future-dated requirements introduced within PCI DSS v4.x became effective from 31 March 2025.

View the current PCI DSS documents.

Map the Current Payment Architecture Before You Switch

Before selecting a replacement provider, document how payments work today.

That should include:

• where the customer enters card details;
• who hosts the payment fields;
• whether the customer is redirected;
• whether an iframe is used;
• whether merchant systems receive cardholder data;
• whether Direct Post is used;
• whether APIs receive payment account data;
• where tokens are created;
• who stores underlying card information;
• whether telephone/MOTO payments are used;
• which systems process refunds;
• which systems contain transaction logs; and
• which third parties can affect payment security.

Then map the proposed new architecture in exactly the same way.

The difference between those two maps tells you much more about potential PCI impact than simply knowing the names of the old and new processors.

Hosted Checkout, iFrame, Direct Post and API Are Not the Same

PCI SSC specifically distinguishes between payment-page architectures when determining SAQ eligibility.

For SAQ A eligibility, all elements used to capture payment account data must originate from compliant third-party service providers, together with all other relevant eligibility criteria.

Read PCI SSC guidance on SAQ A and SAQ A-EP eligibility.

Do You Need a New SAQ When Changing Processor?

Not automatically.

The 2025 version of this guide previously suggested that a new SAQ would be required in most cases simply because the provider changed.

That is too broad.

The relevant question is whether the merchant still meets the eligibility criteria for its existing validation route under the new payment setup.

For example:

• a hosted-to-hosted migration may potentially retain similar SAQ eligibility;
• moving to an embedded payment architecture may change which requirements are relevant;
• moving to Direct Post may change eligibility;
• moving to a merchant-controlled API could significantly expand PCI scope; or
• removing cardholder data from merchant systems could potentially reduce scope.

PCI SSC advises merchants to confirm the appropriate SAQ and validation requirements with the relevant acquiring bank, payment brand or other compliance-accepting entity.

MAS View

Do not ask the new PSP only “Which SAQ do your merchants complete?”

Ask:

“Which SAQ may apply to our specific implementation, and what should we confirm with our acquirer?”

SAQ A Has Important Ecommerce Requirements in 2026

Merchants should not assume that using SAQ A means the ecommerce website itself is outside the PCI security discussion.

PCI SSC's current SAQ A guidance includes security considerations for merchant ecommerce webpages.

For merchants using embedded third-party payment pages or forms, PCI SSC requires the merchant to confirm that its ecommerce site is not susceptible to script attacks that could affect the ecommerce system.

Read PCI SSC FAQ 1588 on ecommerce script security.

New for 2026: ASV Scanning Can Still Apply to SAQ A Merchants

This is particularly relevant when changing ecommerce payment processor.

In June 2026, PCI SSC clarified that PCI DSS v4.x SAQ A includes requirements for external vulnerability scanning by a PCI SSC Approved Scanning Vendor for relevant merchant ecommerce webpages.

PCI SSC states that this includes merchants whose webpages:

• redirect customers to a third-party payment service provider; or
• contain a third-party provider's embedded iframe.

The reason is that compromise of the merchant-controlled webpage could interfere with the payment journey even if payment processing itself is outsourced.

Read PCI SSC's June 2026 SAQ A ASV guidance.

Why This Matters During Migration

A merchant might assume:

“Provider B hosts the payment form, therefore our website vulnerability position is irrelevant.”

That is not a safe assumption under the current guidance.

The merchant-controlled website can still affect:

• redirect destinations;
• checkout scripts;
• iframe behaviour;
• customer navigation;
• malicious code injection; and
• payment-page integrity.

Switching Providers Can Be an Opportunity to Reduce PCI Scope

A provider migration does not have to replicate the old architecture.

It can be an opportunity to ask whether the business needs to handle as much card data as it currently does.

For example, a merchant might move from:

merchant-controlled card capture

to:

provider-controlled tokenised payment components.

That could reduce the amount of sensitive payment data interacting with merchant systems, depending on the final implementation.

This can potentially reduce:

• security exposure;
• compliance complexity;
• systems within scope;
• developer responsibilities; and
• the impact of future payment changes.

PCI architecture should therefore be discussed during provider selection rather than after the integration has already been designed.

But Do Not Reduce PCI Scope at the Expense of Payment Strategy

The lowest-scope architecture is not automatically the right commercial payment architecture.

An established merchant may also need:

• advanced subscriptions;
• complex tokenisation;
• multiple acquirers;
• custom payment logic;
• split payments;
• multi-entity processing;
• local acquiring;
• payment orchestration;
• advanced reconciliation; or
• deep API integration.

The objective should be:

only handle cardholder data where there is a justified business reason to do so.

For broader architecture planning, see our Payment API Integration guide.

Stored Cards and Tokens Need to Be Reviewed Before the Switch

If customers have cards stored for future use, establish exactly how those credentials work before terminating the current provider.

Ask:

• Who holds the underlying account data?
• Who created the token?
• Is the token only usable within the current PSP?
• Can payment credentials be migrated?
• Will the migration involve PCI DSS compliant provider-to-provider transfer?
• Will customers need to re-enter their card information?
• How will subscriptions continue during migration?
• What happens to card-on-file transactions?

The safest migration route may involve providers transferring underlying payment credentials directly rather than the merchant receiving raw card data itself.

The exact process depends on both providers and the merchant's PCI environment.

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

Do Not Export Card Data Into a Spreadsheet During Migration

A payment-provider move can create pressure for quick technical workarounds.

This is exactly when sensitive payment information can accidentally move into systems that were never designed to hold it.

Avoid ad-hoc processes such as:

• exporting card numbers to spreadsheets;
• sending payment credentials by email;
• copying sensitive data into support tickets;
• placing payment account data into shared cloud drives;
• moving raw card data through non-compliant development tools; or
• asking customers to send card details manually.

If payment credentials need to migrate, agree a compliant transfer process with the old and new providers.

Test Environments Can Accidentally Expand PCI Scope

Development teams should avoid using live cardholder data in test environments unless the environment has been designed and assessed appropriately.

During migration, check:

• development environments;
• staging environments;
• API logs;
• debugging tools;
• error monitoring;
• screenshots;
• support tickets;
• analytics platforms; and
• developer collaboration tools.

The fact that a system is “only temporary” does not make sensitive payment data safe to place there.

Check Your Logging Before Going Live

A new API integration can unintentionally log more information than the old setup.

Review:

• API request logs;
• API response logs;
• webhook payloads;
• application errors;
• customer-service tools;
• fraud platforms;
• observability software; and
• third-party monitoring tools.

The new payment integration should be designed so sensitive payment account data is not unnecessarily copied into downstream systems.

Third-Party Provider Responsibilities Need to Be Remapped

Changing processor means the business may also change which third parties are responsible for particular PCI DSS controls.

The new environment may include:

• acquirer;
• PSP;
• payment gateway;
• tokenisation provider;
• ecommerce platform;
• hosting provider;
• fraud provider;
• call-centre provider;
• payment orchestration platform; and
• other technology providers.

The merchant should understand:

• which organisation performs which function;
• which providers are relied on for PCI DSS requirements;
• what evidence of provider compliance is available;
• which controls remain the merchant's responsibility; and
• whether old providers can be removed from the merchant's third-party inventory after migration.

Do Not Close the Old Processor Too Early

PCI DSS is not the only reason to keep the old environment operational for a period.

Historic transactions may still require:

• refunds;
• chargebacks;
• retrieval requests;
• subscription management;
• historic reporting;
• reserve releases;
• settlement adjustments; and
• customer-service investigation.

Before switching off old systems, establish what data must be retained and for how long, who requires access and what security controls continue to apply.

Historic Data Should Not Simply Be Copied to the New Provider

Merchants should distinguish between:

• transaction reporting;
• customer records;
• payment tokens;
• underlying cardholder data;
• refund references; and
• chargeback evidence.

Not every data set needs to be migrated in the same way.

Minimising unnecessary storage remains an important PCI DSS principle.

What About Card Machines?

A face-to-face processor migration can also change PCI considerations.

Review:

• whether terminals are standalone or integrated;
• EPOS connectivity;
• network configuration;
• terminal management;
• remote-access software;
• whether validated P2PE is used;
• what happens to the old terminals; and
• whether stored configuration or payment data needs to be securely removed.

Replacing one terminal model with another is not automatically a like-for-like PCI change.

What About MOTO and Virtual Terminals?

If staff take card details over the telephone, switching virtual-terminal provider may change:

• which devices are used;
• which employees access the system;
• how authentication works;
• whether calls are recorded;
• whether card details appear in recordings;
• how temporary notes are handled; and
• which systems are within the payment environment.

Do not assume a browser-based virtual terminal means the merchant's wider MOTO process is automatically outside PCI scope.

Payment Links Can Change the PCI Architecture

A provider change may also be an opportunity to replace telephone card capture with payment links.

Instead of staff asking customers to read card details aloud, a provider-hosted payment link can allow customers to enter their payment details directly into the provider's environment.

This can reduce direct merchant handling of cardholder data, depending on the implementation.

When Should PCI Be Reviewed During a Provider Migration?

Before Provider Selection

Understand the current architecture and decide whether reducing unnecessary card-data handling is a design objective.

During Provider Comparison

Ask each provider how card data is captured, tokenised and stored.

Before Development

Confirm the proposed architecture and likely PCI validation route.

During Testing

Check logs, development systems, API payloads and temporary migration processes.

Before Go-Live

Confirm relevant validation, scanning and provider responsibilities.

After Go-Live

Remove old systems and provider access only when historic operational requirements are understood and securely managed.

What Should You Ask a New Processor About PCI DSS?

Find Your New Processor

The MAS PCI Migration Test

When reviewing a processor change, we would separate the PCI question into six areas.

1. Current Architecture

How does card data interact with the merchant today?

2. Proposed Architecture

Will the new setup increase, reduce or broadly preserve merchant interaction with cardholder data?

3. Validation

Does the new architecture affect SAQ eligibility, ASV scans or another validation requirement?

4. Stored Credentials

Can tokens and stored payment credentials move without exposing raw card data to merchant systems?

5. Migration Security

Are development, testing, logging and temporary data-transfer processes appropriately designed?

6. Old Environment

What needs to remain live for refunds, disputes, reporting and historic transactions, and when can it be securely retired?

MAS View

A payment migration is one of the best opportunities a business has to reduce unnecessary PCI DSS complexity — but only if PCI architecture is considered before the new integration is built.

How Merchant Advice Service Approaches PCI During Payment Provider Changes

Merchant Advice Service is not a Qualified Security Assessor and does not certify merchants as PCI DSS compliant.

Our role is to consider PCI architecture as part of the wider payment-provider decision.

When a business changes processor, we may look at:

• current payment architecture;
• proposed checkout model;
• gateway structure;
• API requirements;
• tokenisation;
• stored cards;
• subscriptions;
• MOTO;
• payment links;
• ecommerce platform integrations;
• multi-acquirer requirements;
• provider portability; and
• the practical migration path.

Formal PCI DSS scope and validation requirements should be confirmed with the relevant acquirer, payment brand or appropriately qualified PCI professional.

For the broader security requirements, see our PCI DSS Compliance Guide.

For complex provider changes, see our Enterprise PSP Migration Guide.

Sources & Further Reading

PCI Security Standards Council — PCI DSS v4.0.1

Official PCI SSC resources containing the current PCI Data Security Standard and supporting documents.

PCI DSS document library

PCI SSC — SAQ A and SAQ A-EP Eligibility

Official guidance explaining how the source of payment-page elements affects eligibility for SAQ A and SAQ A-EP.

PCI SSC SAQ eligibility guidance

PCI SSC — Ecommerce Script Security

Current guidance explaining the SAQ A eligibility requirement concerning script attacks affecting embedded ecommerce payment forms.

PCI SSC FAQ 1588

PCI SSC — SAQ A and ASV Scanning

June 2026 clarification confirming external vulnerability scanning requirements for relevant SAQ A ecommerce webpages using redirects and embedded third-party iframes.

PCI SSC FAQ 1604

Related Merchant Advice Service Guidance

• PCI DSS Compliance for UK Businesses
• Changing Payment Provider With a Custom API
• Moving Stored Cards, Tokens and Recurring Payments
• Payment API Integration
• Acquirer-Agnostic Payment Gateways
• Merchant Services Contract Renewal
• Compare UK Payment Providers
• Payments Strategy Library

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 PCI DSS information or provider-selection principles included in this article.

Merchant Advice Service is not the PCI Security Standards Council and is not a Qualified Security Assessor.

Changing processor does not automatically determine a merchant's PCI DSS scope or validation requirements. These depend on the merchant's specific payment architecture and the requirements of the relevant payment brands, acquiring provider or other compliance-accepting entity.

The payment scenarios and SAQ examples in this guide are illustrative and should not be treated as a formal PCI DSS scope assessment.

Merchants should confirm their individual PCI DSS validation requirements with their acquiring provider and, where appropriate, an appropriately qualified PCI professional.

Payment-provider technology, PCI DSS guidance and validation requirements can change.

PCI DSS information last checked: 26 August 2026

Article last reviewed: August 2026

This guide provides general payment information and should not be treated as legal, cybersecurity, regulatory or formal PCI DSS compliance advice.