PCI DSS 4.0.1 for PSPs & Gateways: What High-Risk Merchants Must Change in 2026

PCI DSS compliance has always been a requirement for anyone handling card payments, but in 2026, its role is very different. What was once viewed as a technical checkbox has now become a defining indicator of operational maturity for PSPs, gateways, and the high-risk merchants who rely on them. With PCI DSS 3.2.1 retired and PCI DSS 4.0 fully withdrawn, version 4.0.1 has become the single accepted standard and with it, a new set of expectations about how payment providers run their platforms day-to-day.

For many organisations, this shift has been gradual. For high-risk merchants, however, the impact is immediate and commercial. Acquirers are now looking far beyond the certificate itself. They want confidence that a PSP’s environment is properly governed, well-monitored, and secure enough to support industries with elevated fraud, chargeback and regulatory exposure.

Below, we outline the key ways PCI DSS 4.0.1 is reshaping payment operations in 2026 and what this means for high-risk merchants choosing a PSP or gateway.

• PCI DSS 4.0.1 is now the single supported version of the standard.
• Annual “check-the-box” compliance is no longer enough; continuous evidence is required.
• High-risk merchants depend heavily on their PSP’s control maturity and documentation discipline.
• PSPs and gateways face higher expectations around authentication, scripting, logging and shared responsibilities.
• Acquirers increasingly use PCI posture to guide onboarding decisions and reserve requirements.

As these expectations evolve, the relationship between merchants and their PSPs is changing. High-risk operators from iGaming platforms and travel aggregators to forex brokers and CBD retailers are now evaluating PCI not as a security topic, but as a business-continuity factor. A PSP’s ability to demonstrate strong PCI governance can speed up onboarding, improve approval rates and reduce the likelihood of reserve increases. A weak PCI posture can do the opposite.

In this environment, PCI DSS 4.0.1 matters because it gives every stakeholder, merchant, gateway, acquirer and regulator a clear reference point. It brings structure and clarity to areas that previously relied too heavily on interpretation, and it creates a framework where both technical controls and operational discipline must align every day, not just at audit time.

Strong PCI DSS 4.0.1 maturity is now one of the clearest signs that a PSP or gateway can protect your business and keep your payments flowing without interruption.

The 2024–2026 PCI Transition Timeline: What Actually Changed

The journey to PCI DSS 4.0.1 didn’t happen in a single announcement; it unfolded over two years of gradual phase-outs, clarifications and new expectations. By 2026, the transition is complete, and PSPs and gateways are expected to operate at full maturity. But to understand why the pressure feels so different now, it helps to look at how we got here.

The Retirement of PCI DSS 3.2.1 (March 2024)

The first major shift came when PCI DSS 3.2.1, the version that defined payment security for almost a decade, was formally retired. This is when the PCI Security Standards Council (PCI SSC) signalled that the older “annual audit and documentation” mindset was no longer enough to manage the realities of modern cyber risk.

This retirement alone forced PSPs and gateways to start evaluating their authentication flows, logging, vulnerability management and hosted payment-page structures under a more modern lens.

PCI DSS 4.0 Arrives: Then Departs (2024)

PCI DSS 4.0 introduced a wave of new ideas: targeted risk analysis, a customised approach, stronger MFA, clearer scoping guidance, and more explicit expectations for service providers. While these changes were welcomed in theory, the industry needed further clarification.

That clarification came in June 2024, with the release of PCI DSS 4.0.1; a cleaned-up, sharper version of 4.0.

Although 4.0.1 didn’t add new requirements, it clarified how several important controls must be interpreted, which removed the ambiguity that had previously caused friction between QSAs and payment providers.

By 31 December 2024, PCI DSS 4.0 was also withdrawn, leaving 4.0.1 as the only supported version.

31 March 2025: The Real Deadline Everyone Feels

While version changes attract attention, the most impactful milestone came three months later. On 31 March 2025, all “future-dated” PCI DSS 4.0 controls officially became mandatory.

These include:

• Full MFA for all access into cardholder data environments
• Authenticated internal vulnerability scanning
• Automated log review mechanisms
• Monitoring for security-control failures
• Stronger change-management rules
• Governance of JavaScript on payment pages
• Expanded service-provider documentation and responsibilities

For PSPs and gateways, this marked the end of flexibility. Controls that were once “recommended preparations” became enforceable expectations with no grace period.

2026: The First Full Year of PCI DSS 4.0.1 in Practice

By 2026, the transition period will be over. PSPs and gateways no longer operate in a mixture of old and new requirements; they are expected to manage every relevant PCI control in real time.

This also aligns with the broader regulatory expectations set out by the European Banking Authority (EBA), which requires PSPs to maintain continuous ICT and security monitoring, resilient operations and clear allocation of responsibilities.

High-risk merchants feel this most clearly. Acquirers now evaluate PCI posture not as paperwork, but as evidence of whether a PSP can safely support sectors such as iGaming, travel, forex, CBD and adult content. Late adoption or partial implementation now translates directly into higher reserves, slower onboarding and stricter monitoring.

2026 is the first true “steady-state” year of PCI DSS 4.0.1. The transition is complete, and payment providers that have not adapted will experience it first in underwriting decisions, and then in their ability to maintain processing continuity.

What PCI DSS 4.0.1 Actually Changes (Clarifications, Not New Controls)

PCI DSS 4.0.1 arrived with a surprising message: nothing “new” had been added. No extra requirements. No sudden obligations. Instead, the goal was to clear up the confusion that PCI DSS 4.0 had unintentionally created. Rather than expanding the rulebook, 4.0.1 focuses on making the existing rules far easier to interpret and far harder to misapply.

For PSPs and gateways, this clarity is more important than it sounds. Ambiguous language has always been one of the biggest friction points in PCI audits. The same control could be interpreted differently by two QSAs, leaving payment providers with uncertainty around tokenisation methods, patching timelines or MFA pathways. With 4.0.1, the PCI Security Standards Council has effectively closed those gaps.

The result is a standard that doesn’t feel heavier, just sharper.

Tokenisation and PAN Protection Become Clearer

One of the biggest clarifications concerns how Primary Account Numbers (PANs) are rendered unreadable. PCI DSS 4.0 initially introduced updated wording around keyed cryptographic hashing, but 4.0.1 tightens this even further.

For PSPs running their own token vaults, this clarity matters. Many legacy vaults were built at a time when PCI’s hashing rules were easier to interpret loosely. Now, the guidance is explicit.

Payment providers must show that their hashing and tokenisation methods follow the intended cryptographic design, not just a technically acceptable workaround.

This doesn’t change how tokenisation works; it changes how cleanly it must be explained and evidenced.

Patching Timelines Leave No Room for Misunderstanding

PCI DSS 4.0 introduced the requirement to patch critical vulnerabilities within 30 days, but real-world implementation varied widely. Some PSPs applied the rule strictly, while others stretched timelines based on internal deployment cycles.

PCI DSS 4.0.1 removes that discretion. The updated wording makes it clear that “within 30 days” means exactly that, and the expectation applies consistently across environments. This aligns with broader regulatory views on ICT risk, particularly in Europe, where operational resilience is treated as a continuous responsibility, not an annual audit exercise.

For PSPs in high-risk sectors, slow patching is now a governance issue, not a technical oversight.

MFA Rules Are No Longer Open to Interpretation

Authentication has always been one of PCI’s most discussed areas. PCI DSS 4.0 introduced stronger MFA controls, but there was confusion around when MFA was mandatory, when phishing-resistant factors made MFA redundant, and how MFA should be layered across different systems.

PCI DSS 4.0.1 clears this up. It explains the exact situations where MFA must apply and provides a clearer distinction between traditional MFA and phishing-resistant authentication.

For PSPs with multiple support teams, engineering access paths and cloud environments, this clarity simplifies everything from architecture design to access audits.

A Stronger Focus on Script Integrity in eCommerce

One of the most practical improvements in PCI DSS 4.0.1 concerns eCommerce script security. With more merchants relying on third-party JavaScript, modern checkouts have become increasingly vulnerable to tampering. Earlier PCI versions didn’t clearly define who was responsible for securing these scripts.

PCI DSS 4.0.1 closes that gap. If a PSP provides a hosted checkout widget, iframe fields or JavaScript libraries that load directly on a merchant’s site, the PSP must now demonstrate how those scripts are governed, monitored and controlled. It is no longer acceptable to leave script responsibilities entirely to merchants. This shift affects almost every gateway offering embedded payment experiences.

Service Provider Responsibilities Are Sharper Than Ever

Perhaps the most meaningful change for PSPs is the emphasis on shared responsibility. PCI DSS 4.0.1 makes it clear that PSPs must maintain accurate, accessible responsibility matrices and updated documentation for every merchant relationship.

That includes:

• Defining exactly which controls the PSP manages
• Clarifying what merchants remain responsible for
• Providing documentation on demand to support merchant audits or acquirer reviews

For high-risk merchants, this removes uncertainty and strengthens trust. For PSPs, it creates a higher expectation of governance and transparency qualities that acquirers increasingly look for when onboarding or reviewing risk.

PCI DSS 4.0.1 isn’t about adding new rules; it’s about removing the ambiguity around existing ones. This clarity brings stronger accountability, tighter system design and more consistent expectations across PSPs, gateways and merchants.

The Controls That Impact PSPs & Gateways the Most

While PCI DSS 4.0.1 doesn’t add new requirements, it does make several existing controls far more demanding for PSPs and gateways. These controls cut right into the core of how payment infrastructure is built and managed, and they place higher expectations on authentication, logging, operational resilience and service-provider governance. For high-risk merchants choosing a PSP, these are often the controls that determine whether a provider feels “enterprise-grade” or still tied to legacy practices.

Below, we break down the areas where PSPs feel the pressure most and why these controls now matter commercially, not just technically.

Stronger Identity & Access Controls: MFA Everywhere It Matters

One of the most noticeable shifts is around user access. Under earlier versions of PCI, MFA tended to focus on administrative roles or remote access. PCI DSS 4.0.1 raises the bar. PSPs and gateways must now enforce MFA across any access point that touches cardholder data or could influence cardholder data security.

This affects everyone, support staff, infrastructure engineers, outsourced DevOps teams, cloud administrators and anyone who uses privileged tools. It also means modern identity systems (SSO, conditional access, phishing-resistant authentication) must be configured correctly rather than assumed to be PCI-compliant by default.

For PSPs with distributed teams or multi-region operations, this becomes a central operational discipline, not an IT configuration decision.

Logging, Monitoring & “Control Health” Become Daily Responsibilities

PCI DSS 4.0.1 strengthens expectations around visibility. Payment providers must show that critical events across their environment, from access violations to unusual system behaviour, are logged, reviewed and acted upon on time. This includes:

• Automated daily log reviews
• Authenticated internal scans
• Monitoring for the failure of security controls themselves
• Clear evidence that alerts are investigated and closed

These requirements support the wider regulatory direction in Europe, where the EBA ICT & Security Guidelines emphasise continuous monitoring and operational resilience.

This isn’t optional for PSPs: acquirers increasingly expect to see proof that logs aren’t just generated, they’re actively used.

A Major New Expectation for eCommerce Gateways

Modern eCommerce relies heavily on JavaScript. It powers checkout fields, payment forms, fraud checks and analytics. But it also introduces a major attack vector: malicious script injection.

PCI DSS 4.0.1 makes it clear that script integrity is not just a merchant obligation. If a PSP’s script loads on a merchant’s checkout, even through a simple embed, the PSP must:

• Control where scripts come from
• Maintain allowlists
• Detect unauthorised changes
• Ensure merchants receive updated versions without delay

This is one of the most operationally difficult parts of PCI for PSPs offering hosted fields, drop-in widgets or hybrid checkout experiences. It requires modern DevSecOps practices and constant monitoring, not a one-time audit.

Governance for Service Providers: Accountability Is Now Measurable

PCI DSS 4.0.1 puts strong emphasis on documentation and shared responsibility. PSPs must maintain clear, updated and accessible responsibility matrices that tell merchants exactly who manages each PCI requirement. This becomes even more important for high-risk verticals, where acquirers look carefully at third-party dependencies.

Requirements such as six-monthly scope reviews, updated RACI documents, change-control logs and test evidence are now part of what makes a PSP “credible” in the eyes of regulators and acquirers.

Put simply: PSPs must demonstrate not only that their environment is secure, but also that their governance model is mature.

The Commercial Impact: Faster Underwriting or Higher Reserves

These control expectations now sit at the centre of how acquirers evaluate payment providers. PSPs and gateways that can demonstrably manage these areas often receive:

• Faster underwriting decisions
• Reduced reserve requirements
• Fewer remediation cycles
• Smoother onboarding for merchants

Those who can’t provide clear evidence face the opposite: delays, additional questions, risk concerns and in some cases, barriers to entering new markets altogether.

These are the controls that determine whether a PSP is built for modern risk. Strong access control, logging, script governance and clear documentation aren’t just “compliance tasks”, they directly influence your onboarding speed, your reserve levels and your ability to stay live in high-risk sectors.

The Customised Approach: When PSPs Should (and Shouldn’t) Use It

PCI DSS 4.0 introduced something new to the payment industry: the option to meet a requirement by achieving its security objective, even if you don’t follow the control exactly as written. PCI DSS 4.0.1 doesn’t change this model, but it clarifies how it should be used and why it requires far more discipline than the traditional “defined” approach.

For PSPs and gateways, especially those built on modern cloud or orchestration layers, the customised approach can provide much-needed flexibility. But it also demands a level of evidence, internal organisation and architectural clarity that many providers underestimate.

Why PCI Introduced a Customised Path in the First Place

Traditional PCI controls were written for older, perimeter-style data environments, think physical servers, simple networks and clear borders. Modern PSPs, however, operate in vastly different conditions:

• Cloud-native environments
• Containerised workloads
• Distributed microservices
• Multi-tenant platforms
• Tokenisation-driven architectures

The customised approach exists to recognise this reality. Instead of forcing PSPs to “fit” their architecture into a control that was written years ago, PCI allows them to prove they can achieve the same level of protection differently.

This makes PCI more adaptable but also more accountable.

When the Customised Approach Makes Strategic Sense

Not every PCI requirement benefits from the customised path. But there are scenarios where it genuinely aligns better with how PSP platforms operate.

In these cases, the customised approach can provide clarity and avoid forcing PSPs into awkward technical workarounds.

The Documentation Burden PSPs Must Prepare For

The flexibility of the customised model comes with a cost: you must prove everything.
Unlike the defined approach, where you simply demonstrate that a control has been implemented correctly, the customised approach requires:

• A detailed Targeted Risk Analysis (TRA)
• Documented justification for the chosen method
• Clear security objectives
• Evidence that consistently meets those objectives
• Repeatable testing procedures
• Alignment with PCI’s intent, not just its text

This creates a substantial operational overhead, especially for PSPs managing large engineering teams or distributed infrastructure.

It’s one of the reasons QSAs treat customised controls with greater scrutiny. If the evidence isn’t clear, the control is not accepted.

The Business Risk of Overusing the Customised Model

For PSPs, the customised approach should never be a shortcut. Acquirers and regulators already expect payment providers to maintain strong, consistent internal governance. When a PSP leans too heavily on customised controls, it can raise concerns such as:

• Is the architecture too complex to maintain safely?
• Are customised controls masking gaps in the environment?
• Will evidence be difficult to produce during underwriting?
• Can the PSP consistently apply this approach across all tenants?

High-risk merchants feel these consequences most. A PSP without predictable PCI controls can experience:

• Slower onboarding approvals
• Increased reserve requirements
• More remediation cycles
• Less confidence from acquirers

In high-risk portfolios, predictability often outweighs flexibility.

When PSPs Should Avoid the Customised Approach Entirely

There are certain parts of PCI where a customised approach introduces more complications than value:

• Authentication and MFA
• Logging and monitoring
• Patching cadence
• Script integrity governance
• Privileged access management

These controls are straightforward and universally understood. Using alternative methods in these areas often creates unnecessary audit friction and can weaken merchant confidence. Sometimes the simplest path is also the strongest.

The customised approach is a powerful tool, but only when used deliberately. PSPs should reserve it for cases where their architecture genuinely demands flexibility, not as a way to avoid traditional PCI requirements. The more predictable a PSP’s controls are, the easier it is for high-risk merchants to trust the environment behind them.

High-Risk Merchant Impact Under PCI DSS 4.0.1

PCI DSS 4.0.1 not only reshape the responsibilities of PSPs and gateways, it also changes what high-risk merchants should expect from their payment partners. By 2026, acquirers will have become much more selective in how they evaluate high-risk portfolios, and PCI posture now plays a direct role in pricing, reserves and even the decision to maintain a merchant account.

What this means in practice is simple: a high-risk merchant is only as compliant as its PSP allows it to be. Weaknesses in a gateway’s logging, tokenisation, authentication or scripting controls now become commercial risks for the merchants they serve. Below, we break down what this shift looks like across different high-risk sectors.

1. iGaming & Betting: Where Identity and Page Integrity Matter Most

iGaming merchants operate in one of the most heavily scrutinised digital environments. With fast-moving deposits, instant withdrawals and high fraud pressure, acquirers expect PSPs to offer more than just basic PCI alignment.

Under PCI DSS 4.0.1, two areas now stand out:

• Script integrity on wallet top-up pages: If a PSP provides embedded scripts, they must prove they’re monitored and tamper-resistant, something regulators have become increasingly concerned about.
• Access control discipline: High-volume operator dashboards require tighter authentication and logging than ever before.

Merchants who rely on PSPs with poor page integrity, inconsistent MFA or weak operational oversight often face reserve increases or onboarding delays.

2. Travel & Ticketing: A Sector Where Checkout Security Drives Underwriting

Travel merchants handle global traffic, multi-currency transactions and bookings across dozens of airlines and carriers. That complexity drives higher chargeback exposure and acquirers now look closely at whether a PSP can support the security model required for cross-border checkout flows.

Under PCI DSS 4.0.1, the biggest impacts include:

• Stronger monitoring of checkout scripts: More important in multi-step booking journeys.
• Authenticated scanning and event logging: Crucial for detecting fraud patterns early.
• Consistent MFA across support and ticketing tools: Especially when PSP staff access booking data.

These factors now influence how quickly a travel merchant gets approved and on what terms.

3. CBD, Supplements & Adult: High Dispute Rates Require Evidence, Not Promises

Merchants in CBD, nutraceuticals and adult entertainment work under stringent acquirer scrutiny. These sectors naturally experience higher refund and chargeback rates, which means acquirers expect PSPs to provide airtight logging, change control and data-handling standards.

With PCI DSS 4.0.1 now fully in force, PSPs serving these merchants must demonstrate:

• Consistent log review workflows
• Fast patching of critical vulnerabilities
• Documented responsibility matrices
• Updated evidence packs for audits

Weak PCI governance now translates directly into tougher commercial conditions, including rolling reserves and shortened settlement cycles.

4. Forex, Trading & On/Off-Ramp Platforms: API Security and System Account Control

Forex and trading platforms rely heavily on automation, APIs, webhooks, CRM integrations and multi-jurisdictional flows. Under PCI DSS 4.0.1, this makes two areas especially important:

• System account governance: API keys, service accounts and automation tools must follow PCI’s clarified access rules.
• Continuous monitoring of environmental health: Because real-time trading systems cannot afford silent control failures.

This aligns with the broader expectations of the European Banking Authority, which emphasises continuous security monitoring for payment institutions. Merchants in this category increasingly choose PSPs based on architectural maturity, not just pricing.

Why High-Risk Merchants Must Start Asking Different Questions

By 2026, high-risk merchants can no longer rely on simple questions like “Are you PCI certified?” They need deeper, operational questions:

• How do you monitor script integrity on your hosted payment pages?
• Do you support authenticated internal vulnerability scans?
• How do you handle MFA for support teams?
• How often is your PCI scope reviewed and documented?
• Can you provide a current responsibility matrix?

The answers to these questions determine whether a merchant can pass underwriting efficiently or whether the PSP becomes a bottleneck.

For high-risk sectors, PCI DSS 4.0.1 isn’t a background compliance topic; it’s a commercial risk indicator. Merchants now depend on PSPs with mature authentication, scripting, logging and governance practices, because acquirers treat these controls as direct predictors of portfolio stability.

Modern Scoping: Cloud, Tokenisation & Multi-Tenant Gateway Architecture

Correct scoping is one of the most underestimated parts of PCI DSS compliance and, for many PSPs and gateways, the area where most findings are discovered in 2026. PCI DSS 4.0.1 doesn’t change the definition of scope, but it clarifies how modern architectures must be assessed. This matters because the majority of PSP environments today are cloud-hosted, API-led and multi-tenant, rather than traditional server-based infrastructures.

In other words, PCI has finally caught up with the way PSPs actually build systems. But with that alignment comes a new expectation: scoping must now be precise, evidence-based and technically accurate, not assumed or inherited.

Cloud Hosting & Virtual Segmentation: What “In Scope” Really Means

Many PSPs assumed early cloud adoption would reduce PCI burdens, especially with “shared responsibility” models. PCI DSS 4.0.1 removes that misconception. Cloud deployments are very much in scope unless the PSP can prove otherwise.

In a cloud-native environment, segmentation must be demonstrated at a far more granular level:

• IAM-based segmentation, where identity and role-based controls separate cardholder-data environments
• Container and pod-level isolation, rather than simple VLANs
• Zero-trust access boundaries, enforced through policies rather than network devices
• Environment-specific service accounts, each with unique permissions
• Automated configuration monitoring, ensuring no drift across regions or tenants

PCI DSS 4.0.1 makes it clear that segmentation is no longer “firewalls + VLANs.” It is an identity-driven, configuration-backed model of isolation that must be inspected and evidenced.

Tokenisation & PAN Handling: How 4.0.1 Tightens the Rules

Tokenisation has always been critical for PSPs, but PCI DSS 4.0.1 forces a deeper examination of how token vaults are built and secured. Earlier PCI versions left room for interpretation; 4.0.1 closes that gap.

Key expectations now include:

• Clear application of keyed cryptographic hashing when rendering PAN unreadable
• Evidence of the cryptographic method used, not just a description
• Documented mapping paths between tokens and original PANs
• Strict access control and logging for vault operations
• Cryptographic key rotation based on documented schedules

For PSPs using custom token vaults, 4.0.1 is a turning point. Many legacy vaults must be redesigned or revalidated to demonstrate alignment with clarified cryptographic guidance.

Tokenisation is no longer just a feature; it is a security control that requires rigorous, continuous evidence

Multi-Tenant Gateways: Isolation Must Be Proved, Not Claimed

Multi-tenant platforms are now the standard for PSPs, but they introduce complexity: many merchants share the same core infrastructure. PCI DSS 4.0.1 does not ban multi-tenancy, but it becomes far more explicit about what must be proven:

• Clear isolation of merchant data and processing paths
• Independent logging visibility, ensuring one merchant cannot see another’s events
• Documented tenant-boundary diagrams, showing how separation is enforced
• Evidence that tenant-level incidents do not propagate across the platform
• Consistent enforcement of access controls across all tenants

For PSPs operating globally, this is especially important. Acquirers now routinely ask for proof of isolation when onboarding high-risk merchants.

This also aligns with the EBA’s ICT & Security Guidelines, which stress the need for operational resilience across distributed systems, not just environment-level security.

Why Incorrect Scoping Leads to Most PCI Failures in 2026

Most PSPs don’t fail PCI because they lack security controls; they fail because their scope definition is outdated, inconsistent or assumed rather than validated.

Typical issues include:

• Treating cloud services as “out of scope” when they are not
• Failing to include CI/CD pipelines used for CDE code deployments
• Excluding service accounts that can indirectly access PAN
• Overlooking shared infrastructure in multi-tenant gateways
• Relying on old network diagrams that no longer reflect the real architecture
• Incorrect assumptions about tokenisation removing all PCI obligations

In 2026, PCI DSS 4.0.1 expects scoping to be a continuous exercise, not an annual conversation. Mis-scoping leads to findings, delays in onboarding merchants and, in high-risk environments, increased reserve requirements.

Most PCI issues in 2026 don’t come from weak security; they come from incorrect scope. Merchants should choose PSPs that understand cloud segmentation, token vault design and multi-tenant isolation, because these scoping decisions determine the strength of the entire compliance foundation.

The 2026 PSP & Gateway Readiness Checklist

By 2026, PCI DSS 4.0.1 will have shifted from an annual certification exercise to a day-to-day operating standard. PSPs and gateways supporting high-risk merchants now face a higher expectation: compliance must be visible, measurable and continuously maintained.

This readiness checklist brings those expectations into a practical, operational format. It highlights what acquirers will look for, what QSAs will ask for, and what high-risk merchants rely on when selecting a PSP.

The checklist is divided into three pillars: technical controls, governance controls, and merchant-facing controls, exactly as required under the 4.0.1 maturity model.

Technical Controls: What Must Be Running Every Day

Technical controls are the backbone of PSP compliance. PCI DSS 4.0.1 strengthens their expectations, making them continuous rather than cyclical.

MFA Everywhere It Matters

Every access point that touches, configures or influences the cardholder data environment (CDE) must enforce MFA, including admin panels, cloud consoles, DevOps tools, support dashboards and third-party management interfaces.

Automated Log Collection & Review

Manual log inspection is no longer acceptable. PSPs must run automated log aggregation, real-time alerts and daily log reviews across:

• Access events
• Authentication failures
• Privileged activity
• Vault interactions
• Script anomalies

This aligns with the broader expectations within EU operational-resilience frameworks.

Continuous Vulnerability Management

Authenticated scanning must be in place for every CDE system, with critical issues remediated within the clarified PCI DSS timeline — not an internal business timeline. Cloud deployments must be scanned with authenticated access, not unauthenticated perimeter tools.

Script-Integrity Monitoring

Any PSP offering hosted fields, JS widgets or embedded checkout flows must implement:

• Allowlists
• Change detection
• Tamper alerts
• Version-control governance

This requirement is now central to underwriting for iGaming, travel and forex merchants.

Security-Control Health Alerts

PCI DSS 4.0.1 emphasises monitoring for control failures, not just security events. PSPs must detect when:

• Logs stop flowing
• MFA is bypassed
• Scans fail
• Scripts change unexpectedly

Controlling health is now as important as controlling implementation.

Governance Controls: What Acquirers Expect PSPs to Demonstrate

Governance is where most PSPs struggle, not because controls don’t exist, but because evidence isn’t organised.

Six-Monthly Scope Reviews

Scoping must be reviewed twice a year and documented. This includes cloud boundaries, tenant isolation, token vault components, and infrastructure that indirectly touches the CDE.

Updated RACI / Responsibility Matrices

PSPs must clearly define what they own and what the merchant owns. Ambiguity creates underwriting concerns, especially for high-risk merchants.

Targeted Risk Analysis (TRA) Library

A library of completed TRAs must be maintained and available for audit. Each customised control must have its own TRA.

Updated Incident-Response Processes

PSPs must demonstrate that incident-response plans reflect their current architecture, including cloud logs, modern alerting tools, CI/CD pipelines and multi-tenant environments.

Acquirers increasingly request incident-response documentation before enabling high-risk processing access.

Merchant-Facing Controls: What Merchants Must Receive in 2026

Merchants cannot complete PCI compliance without accurate PSP documentation. Under 4.0.1, PSPs must provide all necessary artefacts.

Updated Attestation of Compliance (AOC)

PSPs must publish a 4.0.1-compliant AOC that clearly lists in-scope services.

Updated SAQ Guidance

Since many controls shifted or clarified, merchants need updated instructions on:

• Which SAQ applies
• What responsibilities must they fulfil
• How to implement script integrity
• How to configure hosted fields or JS widgets securely

Integration & Script-Management Documentation

This is a newly scrutinised area. PSP integration guides must include:

• Script version management
• Allowlist management
• CSP (Content Security Policy) recommendations
• Guidance for merchant-side scanning

Clear Role Definition Between PSP and Merchant

Under 4.0.1, shared responsibilities must be documented with no gaps. Merchants should know exactly what is expected from them to remain compliant.

A PSP that is “2026-ready” isn’t just compliant, it is predictable. It maintains strong technical controls, disciplined governance and clear merchant guidance. These factors directly impact onboarding speed, reserve requirements and long-term processing stability.

Case Study: How a Gateway Achieved Full 4.0.1 Readiness Before the Deadline

Not all PSPs entered the PCI DSS 4.0.1 era at the same level of maturity. Some had strong foundations but outdated documentation. Others had modern cloud environments but weak governance. And a few underestimated how quickly acquirers would tighten their expectations once 3.2.1 and 4.0 were retired.

This case study looks at a mid-size, EU-based payment gateway serving high-risk merchants across iGaming, travel and CBD. The business wasn’t starting from scratch; it had a functioning PCI programme, but by mid-2024, it became clear that “passing the audit” would no longer be enough. The gateway needed to meet 4.0.1 standards and demonstrate operational maturity that reassured acquirers and merchants.

The Initial Challenges

When the gateway reviewed its environment against PCI DSS 4.0.1, several pain points emerged:

• MFA wasn’t consistently enforced across cloud consoles, support dashboards and engineering tools.
• Internal log review was partially manual, leading to missed alerts and inconsistent evidence.
• Authenticated vulnerability scanning was not deployed across the full CDE.
• Hosted payment-page scripts lacked integrity monitoring and clear documentation for merchants.
• Responsibility matrices were outdated and incomplete.
• The PCI scope diagram still reflected an old network topology rather than the actual cloud structure.

Individually, these issues weren’t catastrophic. But together, they signalled a PCI programme that would not meet 2026 expectations, and would likely slow down merchant onboarding.

Re-Architecting MFA and Identity Controls

The first transformation priority was identity. The gateway moved to:

• Full MFA across all privileged and support roles
• Phishing-resistant methods for admin and engineering access
• Role-based access reviews
• Removal of inactive or shared accounts
• Automated access reporting for audits

This aligned the company with PCI DSS Requirements 7 and 8 and matched the expectations under modern EU ICT-risk rules.

Most importantly, identity became centralised, removing the inconsistency that previously existed across tools.

Fixing Logging & Scanning Gaps

Next, the gateway turned to monitoring. The team deployed:

• Centralised log aggregation
• Daily automated log reviews
• Alerting for unusual authentication patterns
• Full authenticated internal vulnerability scanning
• A “control health” dashboard to detect scanning or log failures

These changes moved the company from “PCI compliant on paper” to continuously monitored in practice.

It also significantly improved merchant confidence, especially in high-risk verticals where chargeback and fraud pressure is high.

Rebuilding Scope Documentation from Scratch

The gateway’s documentation still reflected its old, pre-cloud network design. Under PCI DSS 4.0.1, that became a major risk.

The company rebuilt its scoping documents to include:

• Updated cloud segmentation
• Diagrams for multi-tenant isolation
• Token vault boundaries
• CI/CD pipeline components
• Third-party service provider connections
• Tenant-specific routing logic

This gave the QSA and later, the acquirer, complete clarity over what was in scope and why.

Supporting Merchant Penetration Testing & Script Governance

A key issue for high-risk merchants was the PSP’s lack of guidance around:

• Hosted-field script changes
• Allowlists
• Tamper detection
• CSP rules

The PSP created new integration documentation, provided merchant-side scanning recommendations and implemented automated alerts for script modifications.

This dramatically reduced the risk of merchant checkout compromise and aligned the gateway with PCI DSS 4.0.1 script-integrity clarifications.

The Results: Higher Approval Rates, Faster Onboarding, Lower Reserves

Most importantly, the PSP gained a new commercial advantage: its PCI posture became a selling point, especially for merchants who previously struggled with compliance bottlenecks.

In 2026, PCI DSS 4.0.1 isn’t something you “pass.” It’s an operating model. PSPs that invest early in MFA, logging, script integrity and modern scoping gain real commercial benefits from faster onboarding to reduced reserves and stronger acquirer trust.

The 2026 Execution Playbook for PSPs & High-Risk Merchants

PCI DSS 4.0.1 marks a turning point. By 2026, the organisations that thrive aren’t the ones who view PCI as a compliance requirement; they are the ones who treat it as an operating discipline. This playbook brings the full journey together. It outlines the principles and behaviours that PSPs and merchants must embed into their daily operations if they want to remain compliant, attractive to acquirers and commercially stable.

The underlying theme is simple: PCI is no longer about controls. It is about culture. Platforms that adopt security-first behaviours outperform those that treat PCI as an annual audit cycle.

Zero-Trust Payment Infrastructure

Zero-trust is no longer a theoretical architecture. For PSPs, it is becoming the expected baseline for PCI and broader ICT-risk frameworks. Under zero-trust principles:

• Every user, system, API and service account is continuously authenticated
• Every connection is verified
• Workloads are isolated by default
• No access path is assumed safe based on the network position

PSPs that adopt zero-trust reduce their PCI scope, shrink attack surfaces and create cleaner, evidence-ready environments. High-risk merchants, especially those in iGaming, travel and forex, benefit because these systems experience fewer outages, fewer access failures and fewer operational incidents.

Zero-trust is no longer optional. It is the direction regulators and acquirers expect PSPs to move toward.

Behavioural & Control-Health Monitoring

A decade ago, PCI was driven by logs. In 2026, PCI is driven by signals, patterns of behaviour that reveal how a system is functioning in real time.

For PSPs, this means monitoring:

• Unusual navigation or admin activity
• Unexpected token vault interactions
• Deviations in API call frequency
• Service accounts performing unfamiliar tasks
• Scripts are loading or behaving inconsistently
• Failure of logging, scanning or MFA controls

PCI DSS 4.0.1 specifically emphasises monitoring for control failures, not just security threats. This is one of the biggest mindset shifts for 2026.

High-risk merchants benefit because behavioural monitoring reduces fraud, improves dispute resilience and strengthens overall platform trust.

Governance-First PCI Operations

Governance is where most PSPs fall behind. Not because they lack controls but because they lack discipline in documenting, reviewing and proving those controls.

A governance-first PCI programme focuses on:

• Six-monthly scope reviews (not annual)
• A maintained library of TRAs
• Current RACI and responsibility matrices
• Updated incident-response processes
• Documented change control for all CDE-affecting updates
• Evidence packs that match the real architecture

This approach removes ambiguity in onboarding conversations and gives acquirers the confidence that the PSP’s environment is stable and well governed.

For high-risk merchants, governance strength translates directly into lower reserves, faster approvals and fewer remediation cycles.

Merchant Assurance as a Product

One of the most important themes for 2026 is the rise of PCI assurance as a merchant-facing capability.

Modern PSPs now treat PCI support as part of their product offering. This includes:

• Updated SAQ guidance
• Clear integration documentation
• Merchant-specific script management instructions
• Clarification of what the PSP handles vs what the merchant must do
• Support for merchant penetration testing
• Timely updates when requirements change

The result is a cleaner, faster onboarding experience for merchants and fewer compliance-driven interruptions throughout the year.

This also improves merchant trust. When a PSP can clearly articulate responsibilities and provide practical guidance, it reduces the likelihood of disputes or account instability.

Continuous Audit Readiness

Finally, 2026 marks the end of the “prepare once a year” PCI model. Continuous readiness is now the norm driven not only by PCI DSS 4.0.1 but also by the operational-resilience direction set by EU and UK regulators.

Continuous audit readiness means:

• Evidence is maintained weekly, not annually
• Controls are tested monthly
• Automation supports log review and scanning
• Access reviews occur every 30–60 days
• Merchants receive updated documentation proactively
• Internal PCI stakeholders meet regularly, not reactively

Gateways that embrace continuous readiness experience smoother QSA assessments, fewer findings and reduced operational friction.

The leaders of 2026 are not the PSPs that simply pass PCI, they are the ones who embed PCI into engineering, architecture, documentation and merchant support. This creates faster onboarding, lower reserves and a significantly stronger commercial position in high-risk markets.

Conclusion

By 2026, PCI DSS 4.0.1 will have moved far beyond its traditional role as a security framework. For PSPs, gateways and high-risk merchants, it has become a commercial differentiator, influencing onboarding times, reserve requirements, acquirer confidence, and even a merchant’s ability to stay live in a regulated environment.

The retirement of PCI DSS 3.2.1 and the withdrawal of PCI DSS 4.0 created a clear dividing line. Providers who modernised early now operate with disciplined MFA, automated logging, script integrity, continuous scanning and clear governance. Providers who delayed face underwriting challenges, repeated remediation cycles and growing scrutiny from acquirers managing high-risk portfolios.

High-risk merchants feel this shift most. Their compliance posture is now tied directly to the maturity of their PSP’s controls. A payment gateway with weak documentation, unclear responsibilities or outdated scoping can inadvertently place a merchant at risk, even if the merchant operates responsibly. PCI DSS 4.0.1 has made the PSP–merchant relationship deeper and more interdependent than ever before.

This is why compliance is no longer enough. The winners of 2026 are the PSPs that operationalise PCI, those that treat security, monitoring, scoping and governance as living processes, not audit-time obligations. These providers not only meet the standard; they build trust with acquirers, speed up merchant onboarding and reduce commercial friction across their entire ecosystem.

To help PSPs and merchants convert this into a practical roadmap, we end with a straightforward 90-day action plan.

---

FAQs