PCI DSS Compliance for UK Businesses: What Merchants Need to Know in 2026

PCI Guide For UK Businesses

If your business accepts card payments, PCI DSS is part of your payment-security responsibilities.

But the amount of work involved depends heavily on how your business takes payments.

A retailer using standalone card terminals, an ecommerce merchant redirecting customers to a hosted payment page and an enterprise business capturing payment data through its own API do not have the same PCI environment.

One of the biggest misconceptions is:

“Our payment provider is PCI compliant, so we do not need to do anything.”

That is not necessarily correct.

Outsourcing payment processing can substantially reduce the systems and card data within your PCI DSS scope, but PCI SSC states that merchants still retain responsibilities when payment processing is outsourced.

The more useful question is:

“Where can payment account data enter, move through or be affected by our systems — and what PCI DSS responsibilities does that create?”

This guide explains PCI DSS v4.0.1 for UK businesses, including ecommerce, hosted checkout, embedded payment forms, APIs, card terminals, telephone payments, stored cards, third-party providers and the latest ecommerce security requirements.

Quick Summary

• PCI DSS stands for Payment Card Industry Data Security Standard.
• PCI DSS v4.0.1 is the current version of the standard supported by the PCI Security Standards Council.
• PCI DSS is intended for entities that store, process or transmit payment account data.
• Using a PCI-compliant PSP or gateway does not automatically remove the merchant's own PCI DSS responsibilities.
• Your payment architecture can materially affect the scope of your PCI DSS assessment.
• A fully hosted redirect can create a different PCI environment from an embedded form, Direct Post or merchant-controlled API checkout.
• The correct Self-Assessment Questionnaire depends on the merchant's specific payment environment and eligibility criteria.
• Merchants should confirm the appropriate validation method with their acquirer or other compliance-accepting entity.
• PCI SSC clarified in June 2026 that SAQ A ecommerce merchants can still have ASV external vulnerability scanning requirements for ecommerce webpages, including where customers are redirected to a payment provider or where a provider iframe is embedded.
• PCI DSS and Strong Customer Authentication/3D Secure are different requirements. One does not replace the other.
• Changing payment provider can change PCI scope if the payment architecture changes.

Find Your New Processor

What Is PCI DSS?

PCI DSS is the Payment Card Industry Data Security Standard.

It is a global payment-security standard designed to protect payment account data.

The PCI Security Standards Council develops and maintains the standard.

The current standard is PCI DSS v4.0.1.

PCI DSS v4.0 was retired at the end of 2024, leaving v4.0.1 as the current supported version.

View the current PCI DSS documents from PCI SSC.

Is PCI DSS a UK Law?

PCI DSS is an industry security standard rather than a standalone UK Act of Parliament.

The PCI Security Standards Council develops the standard but does not itself enforce merchant compliance.

Payment brands, acquiring banks and other organisations responsible for compliance programmes determine how merchants are expected to validate and report compliance.

PCI SSC refers to these organisations as compliance-accepting entities.

Read PCI SSC guidance on compliance-accepting entities.

MAS View

Do not treat PCI DSS as a certificate that sits independently from your payment setup.

Your acquiring provider, payment architecture and the way card data interacts with your business determine much of the practical compliance journey.

Does Every Business Taking Cards Need to Think About PCI DSS?

Yes.

PCI SSC states that PCI DSS is intended for entities involved in payment processing, including merchants, regardless of size or transaction volume.

What varies is the merchant's environment and the way compliance must be validated.

A small merchant using a simple outsourced payment setup may have a much smaller compliance scope than a large merchant operating its own payment infrastructure.

See PCI SSC guidance for smaller merchants.

Using a PCI-Compliant Payment Provider Does Not Remove All Merchant Responsibility

This is probably the most important misconception to correct.

A business may use:

• a PCI DSS compliant gateway;
• a hosted checkout;
• a PSP;
• a payment link;
• a card terminal provider; or
• another third-party payment service.

Outsourcing card-data processing can significantly reduce the merchant's PCI DSS scope.

But PCI SSC states that outsourcing all payment-processing operations does not remove the merchant's responsibility entirely.

Merchants can still be responsible for matters including:

• ensuring relevant third-party providers are PCI DSS compliant for the services being used;
• understanding the division of responsibilities between merchant and provider;
• maintaining appropriate agreements with relevant third-party service providers;
• monitoring relevant provider compliance status; and
• completing the applicable PCI validation process.

Read PCI SSC's guidance on outsourced payment processing.

Your Payment Architecture Determines Your PCI Environment

The words “we take payments online” are not enough to establish PCI scope.

You need to understand how the payment actually works.

This table is illustrative rather than a determination of which Self-Assessment Questionnaire applies to a particular merchant.

Businesses should confirm their specific validation requirements with their acquiring provider or relevant compliance-accepting entity.

What Is a PCI Self-Assessment Questionnaire?

A Self-Assessment Questionnaire, usually shortened to SAQ, is one of the tools used by eligible merchants to assess and report PCI DSS compliance.

There are different SAQs for different payment environments.

PCI SSC states that all of the eligibility criteria for a particular SAQ must be met before that questionnaire can be used.

Read PCI SSC's explanation of Self-Assessment Questionnaires.

Which PCI SAQ Do I Need?

There is no single SAQ for every merchant.

Common merchant SAQ categories include:

• SAQ A;
• SAQ A-EP;
• SAQ B;
• SAQ B-IP;
• SAQ C;
• SAQ C-VT;
• SAQ P2PE; and
• SAQ D for Merchants.

Which one applies depends on factors including:

• whether payments are ecommerce, face-to-face or MOTO;
• whether account data is handled by merchant systems;
• whether checkout is outsourced;
• whether payment-page elements originate from the merchant;
• whether terminals connect to other systems;
• whether validated point-to-point encryption is used;
• whether card data is stored; and
• whether all eligibility criteria for the relevant SAQ are met.

PCI SSC recommends consulting the acquiring bank/payment brand or other compliance-accepting entity to confirm which SAQ should be used.

See PCI SSC guidance on choosing an SAQ.

MAS View

Do not select an SAQ simply because another business that looks similar uses it.

Small technical differences in checkout architecture can create materially different PCI DSS requirements.

What Is SAQ A?

SAQ A is designed for eligible card-not-present merchants whose account-data functions are outsourced to PCI DSS compliant third parties and who meet all of the relevant SAQ A eligibility criteria.

It can apply to ecommerce and certain mail-order/telephone-order environments.

For ecommerce, the precise architecture matters.

PCI SSC states that to meet relevant SAQ A payment-page criteria, payment-page elements used to capture payment data must originate from compliant third-party providers rather than the merchant's own environment.

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

Hosted Redirect and Embedded iFrame Are Not Exactly the Same for PCI

A hosted redirect sends the customer from the merchant environment to a payment page controlled by a third-party payment provider.

An iframe allows payment-provider-controlled payment fields to appear inside the merchant's webpage.

Both can potentially reduce merchant exposure to cardholder data compared with directly collecting card details.

However, the security considerations are not identical.

PCI SSC specifically distinguishes between:

• redirect-based ecommerce;
• provider-controlled iframes;
• Direct Post; and
• merchant-generated payment pages.

See PCI SSC guidance on Direct Post, iframe and redirect implementations.

The 2025 Ecommerce Script Changes Matter

PCI DSS v4.0.1 introduced a stronger focus on ecommerce payment-page security.

From 2025, new requirements around payment-page scripts and unauthorised changes became effective within PCI DSS v4.x.

For merchants validating using SAQ A, PCI SSC subsequently revised the questionnaire so that relevant merchants must confirm that their ecommerce site is not susceptible to script attacks that could affect the merchant's ecommerce systems.

This is particularly relevant where a payment-provider form or iframe is embedded within a merchant-controlled webpage.

PCI SSC states that relevant merchants can address the SAQ A eligibility criterion through appropriate techniques or through confirmation from the PCI DSS compliant provider supplying the embedded payment page/form, subject to the published conditions.

Read PCI SSC FAQ 1588 on ecommerce scripts.

New for 2026: SAQ A Ecommerce Merchants and ASV Scanning

This is an important point for businesses that believe a hosted payment setup means vulnerability scanning cannot apply to them.

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 merchant ecommerce webpages.

PCI SSC states that this can apply even where:

• the merchant webpage redirects customers to a third-party payment provider; or
• the merchant webpage contains the payment provider's embedded iframe.

The reasoning is that compromise of the merchant's webpage could potentially interfere with the payment journey even where payment processing itself is outsourced.

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

What Is an ASV?

ASV stands for Approved Scanning Vendor.

An ASV is a company approved by PCI SSC to perform the external vulnerability scans required in relevant PCI DSS environments.

Whether and how scans are required depends on the merchant's specific validation requirements.

Why Ecommerce Security Matters Even When the PSP Hosts the Payment Fields

A criminal does not necessarily need direct access to the PSP's infrastructure to attack the payment journey.

If the merchant's website is compromised, malicious code could potentially:

• alter a checkout link;
• change a redirect;
• inject malicious scripts;
• interfere with payment-page behaviour;
• send customers to a fraudulent payment page; or
• capture information before or around the payment interaction.

This is one reason modern PCI DSS places greater emphasis on the security of ecommerce pages and scripts.

Does Shopify, Stripe or Another PSP Handle PCI for Me?

A hosted ecommerce platform or PSP can significantly reduce the amount of cardholder data handled directly by your business.

That can be extremely valuable.

However, saying:

“Our provider is PCI compliant”

is not the same as saying:

“Our business has no PCI responsibilities.”

The merchant still needs to understand:

• what the provider is responsible for;
• what the merchant is responsible for;
• how checkout is implemented;
• whether plugins/scripts can affect payment security;
• which SAQ or validation route applies;
• whether external scans are required;
• how provider compliance is evidenced; and
• what happens if the payment architecture changes.

PCI Compliance for Card Machines

Face-to-face merchants have different payment environments from ecommerce merchants.

The PCI scope can depend on:

• the type of terminal;
• whether it is standalone;
• whether it connects to EPOS;
• network connectivity;
• how card data moves;
• whether card data reaches merchant systems;
• terminal management;
• remote-access tools; and
• whether validated point-to-point encryption is used.

What Is P2PE?

P2PE stands for Point-to-Point Encryption.

A validated PCI P2PE solution can reduce the merchant's PCI DSS scope by encrypting account data from the point where the card is captured through to the secure decryption environment.

However, simply saying a terminal uses “encryption” does not necessarily mean the merchant is using a PCI-listed P2PE solution.

The specific solution and implementation need to be checked.

View PCI SSC P2PE resources.

PCI DSS for Telephone Payments and MOTO

MOTO means Mail Order / Telephone Order.

Telephone payments can create additional PCI considerations because staff may hear or handle card details.

Questions include:

• Are card details written down?
• Are calls recorded?
• Can card numbers enter call recordings?
• Are staff manually entering card data into a virtual terminal?
• Which computers are used?
• Are those devices properly secured?
• Can employees copy or store payment data?
• Is a payment link a safer alternative for that payment journey?

A virtual terminal supplied by a PCI-compliant provider does not automatically remove the merchant's responsibilities around the people, devices and processes used to access it.

Payment Links Can Reduce Card-Data Handling

Payment links can be useful where a merchant currently asks customers to provide card details over the telephone or email.

Instead, the merchant can send the customer to a payment page controlled by the payment provider.

This can reduce the need for staff to handle payment account data directly.

But the merchant should still check:

• which PCI validation route applies;
• how links are generated;
• who controls the payment page;
• how customer identity is verified;
• how phishing risks are managed; and
• whether staff ever receive card details outside the payment link.

Never Ask Customers to Email Card Details

Email is generally an inappropriate way to collect payment-card information.

If customers regularly send card details by email, the merchant should review the underlying payment journey and provide a more secure payment method.

Payment links, hosted checkout and properly designed payment interfaces can often provide safer alternatives.

Stored Cards and Tokenisation

Many merchants need to retain the ability to charge customers again without asking them to re-enter a card every time.

Examples include:

• subscriptions;
• membership businesses;
• hotels;
• booking platforms;
• SaaS;
• marketplaces;
• repeat ecommerce customers; and
• businesses using merchant-initiated transactions.

Modern payment providers often use tokenisation so that the merchant can reference a payment credential without directly storing the underlying card number.

This can reduce exposure to cardholder data.

But the merchant should establish:

• who stores the underlying card data;
• who creates the token;
• whether the token is provider-specific;
• whether merchant systems ever receive the PAN;
• how tokens are secured;
• how access is controlled; and
• what happens if the provider changes.

For migration issues, see our guide to moving stored cards, tokens and recurring payments.

Direct Payment API Integrations Can Increase PCI Scope

A bespoke API can give an established merchant greater control over:

• checkout;
• payment logic;
• routing;
• tokens;
• subscriptions;
• refunds;
• reconciliation; and
• customer experience.

But the PCI implications depend on what data merchant systems actually touch.

If payment account data enters merchant-controlled:

• applications;
• servers;
• logs;
• databases;
• analytics;
• support systems; or
• network infrastructure,

the compliance environment can become substantially more complex.

PCI DSS scope should therefore be considered before payment architecture is built rather than after integration is complete.

See our Payment API Integration guide for the wider architecture considerations.

Be Careful With Logging

Payment APIs create large quantities of technical data.

Developers should ensure sensitive payment information is not unintentionally captured in:

• application logs;
• error logs;
• support tickets;
• debugging tools;
• analytics platforms;
• monitoring tools; or
• customer-service systems.

PCI DSS scope is not limited to the checkout page itself.

Third-Party Providers Need to Be Managed

Merchants increasingly depend on several third parties within the payment environment.

These can include:

• payment gateways;
• PSPs;
• acquirers;
• hosting companies;
• ecommerce platforms;
• fraud providers;
• tokenisation providers;
• call-centre technology;
• software vendors; and
• other providers capable of affecting the security of payment account data.

PCI SSC states that outsourcing does not remove the merchant's responsibility to understand the relevant third-party relationships.

This includes establishing which provider is responsible for which controls.

Do Not Assume a Provider Is PCI Compliant Because Its Website Says “Secure”

Security marketing language and PCI DSS validation are different things.

Where provider PCI status is relevant to the merchant's assessment, obtain appropriate evidence and understand:

• which legal entity has been assessed;
• which services are covered;
• the period covered by the validation;
• the provider's responsibilities;
• the merchant's responsibilities; and
• whether the service you actually use falls within the validated environment.

PCI DSS and 3D Secure Are Not the Same Thing

PCI DSS protects payment-account data and the systems that store, process, transmit or can affect its security.

3D Secure is an authentication protocol used within ecommerce card payments.

Strong Customer Authentication is a separate regulatory requirement applying to relevant electronic payments under UK payment rules.

They can interact within the same checkout, but:

PCI DSS compliance does not mean SCA is satisfied.

and:

using 3D Secure does not mean PCI DSS is satisfied.

Does PCI DSS Stop Fraud or Chargebacks?

No security standard can guarantee that fraud or disputes will disappear.

PCI DSS is primarily concerned with protecting payment account data and the security of the payment environment.

Merchants may still need separate controls for:

• fraud screening;
• 3D Secure;
• card testing;
• account takeover;
• chargebacks;
• refund abuse;
• subscription disputes; and
• customer authentication.

Do Merchant PCI Levels Still Matter?

Businesses may encounter references to merchant PCI levels based on transaction volumes.

However, merchants should be cautious about relying on an old generic “Level 1 to Level 4” table copied from historic guidance.

PCI SSC states that payment brands and acquirers manage their own compliance-validation programmes.

Those organisations determine matters including:

• who must validate;
• what evidence is required;
• whether an SAQ can be used;
• whether a Report on Compliance is required;
• scanning requirements; and
• submission deadlines.

The correct approach is therefore to confirm current validation requirements with the relevant acquirer or payment brand rather than relying solely on a generic transaction-volume chart.

See PCI SSC guidance on compliance validation.

What Is a Report on Compliance?

A Report on Compliance, usually abbreviated to ROC, is a formal report used for certain PCI DSS assessments.

Not every merchant completes a ROC.

Whether a merchant must validate through a ROC, SAQ or another process is determined by the applicable compliance programme and merchant circumstances.

What Is an Attestation of Compliance?

An Attestation of Compliance, or AOC, records the outcome of a PCI DSS assessment.

AOCs exist for different assessment types.

The merchant should follow the submission requirements specified by its acquiring provider/payment brand or other compliance-accepting entity.

What Happens If You Change Payment Provider?

Changing PSP or acquirer does not automatically make the merchant more or less PCI compliant.

The important question is:

Does the payment architecture change?

Example 1: Hosted Checkout to Hosted Checkout

If one fully hosted payment page is replaced by another similar architecture, the merchant's PCI environment may remain broadly similar, subject to the specific implementations.

Example 2: Hosted Checkout to Embedded Direct Post

The merchant becomes more involved in the payment page, which can change PCI requirements.

Example 3: Hosted Checkout to Direct API

If merchant systems begin handling payment account data directly, PCI scope can increase substantially.

Example 4: Direct API to Provider Tokenised Components

Redesigning the architecture may reduce the amount of card data touching merchant systems.

For the dedicated migration discussion, see How Does PCI Compliance Work When Changing Your Card Processor?

PCI Scope Should Be Part of Provider Selection

When businesses compare processors, they often focus on:

• price;
• authorisation rates;
• settlement;
• payment methods;
• API capability;
• reporting; and
• contract terms.

PCI architecture should sit alongside those considerations.

Ask each shortlisted provider:

• How is card data captured?
• Does our system ever receive PAN data?
• Is checkout hosted, embedded or merchant-generated?
• Which SAQ do merchants using this implementation typically complete?
• What should we confirm with our acquirer?
• Are ASV scans likely to be required?
• How are ecommerce scripts protected?
• Who stores payment credentials?
• How does tokenisation work?
• What PCI evidence does the provider supply?
• What responsibilities remain with us?
• What changes if we add subscriptions or MOTO?
• What changes if we integrate directly via API?

Find Your New Processor

The MAS PCI Scope Test

Before comparing payment technology, we would ask six questions.

1. Where Does Card Data Enter?

Does the customer enter payment information directly into provider-controlled infrastructure, or does merchant technology capture any part of it?

2. What Merchant Systems Can Affect the Payment Journey?

Consider websites, servers, plugins, APIs, EPOS, call-centre systems and employee devices.

3. Where Is Card Data Stored?

Is the underlying account data stored by the merchant, PSP, vault provider or another third party?

4. Which Third Parties Are Involved?

Identify payment processors, gateways, hosting companies, software providers and other suppliers that can affect payment security.

5. What Validation Route Applies?

Confirm the correct SAQ, scans, ROC or other requirements with the acquiring provider or applicable compliance-accepting entity.

6. What Happens When the Payment Setup Changes?

Adding a new checkout, gateway, telephone-payment channel, subscription product or direct API can change PCI DSS scope.

MAS View

The best way to reduce PCI complexity is often to design the payment architecture so unnecessary card data never enters the merchant environment in the first place.

PCI DSS Questions to Ask Before Choosing a Payment Provider

How Merchant Advice Service Approaches PCI When Reviewing Payment Providers

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

However, PCI architecture is relevant when comparing payment providers because different payment integrations can create very different technical and operational requirements.

When reviewing a payment setup, we consider areas such as:

• how the merchant currently takes payments;
• which systems are involved;
• whether checkout is hosted or merchant controlled;
• whether card data enters merchant systems;
• tokenisation;
• stored credentials;
• subscriptions;
• MOTO;
• payment links;
• API requirements;
• ecommerce platform integrations;
• provider portability; and
• how a proposed change could affect the payment architecture.

Merchants should confirm their formal PCI DSS scope and validation requirements with their acquiring provider, payment brand or appropriately qualified PCI professional.

For more about the MAS provider-selection process, see How Merchant Advice Service Works and How MAS Researches and Compares Payment Providers.

Sources & Further Reading

PCI Security Standards Council — PCI DSS v4.0.1

The official PCI SSC document library containing the current PCI Data Security Standard and related supporting materials.

PCI DSS v4.0.1 document library

PCI SSC — Outsourcing Payment Processing

Current guidance explaining that outsourcing card processing does not remove all merchant PCI DSS responsibilities.

PCI DSS and outsourced payment processing

PCI SSC — Self-Assessment Questionnaires

Official guidance explaining SAQs, eligibility criteria and the role of acquiring providers/payment brands in determining validation requirements.

What is a PCI DSS Self-Assessment Questionnaire?

PCI SSC — Ecommerce Script Security

Current guidance on the SAQ A eligibility requirement concerning script-based attacks affecting ecommerce payment environments.

PCI SSC FAQ 1588

PCI SSC — SAQ A ASV Scanning

June 2026 guidance explaining external vulnerability scanning requirements for ecommerce webpages used by SAQ A merchants, including relevant redirect and iframe implementations.

PCI SSC FAQ 1604

PCI SSC — Compliance Validation

Official guidance explaining the role of payment brands, acquiring providers and other compliance-accepting entities in determining PCI DSS validation and reporting requirements.

PCI SSC compliance validation guidance

Related Merchant Advice Service Guidance

• PCI Compliance When Changing Card Processor
• Payment API Integration
• Changing Payment Provider With a Custom API
• Moving Stored Cards, Tokens and Recurring Payments
• Payment Gateways for High-Risk Merchants
• Subscription Payment Processing
• Acquirer-Agnostic Payment Gateways
• 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 factual information, PCI DSS guidance 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.

PCI DSS scope and validation requirements depend on the merchant's individual payment environment and the requirements of the relevant payment brands, acquiring provider or other compliance-accepting entity.

The payment scenarios and SAQ descriptions in this guide are illustrative and should not be used as a definitive PCI DSS scope assessment.

Using a payment provider, hosted payment page, tokenisation service, gateway or ecommerce platform does not automatically eliminate a merchant's PCI DSS responsibilities.

Merchant Advice Service does not certify PCI DSS compliance and does not provide information-security, legal or regulatory assurance.

Businesses requiring formal assessment should consult their acquiring provider and, where appropriate, a Qualified Security Assessor or other appropriately qualified PCI professional.

PCI DSS information last checked: 26 August 2026

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