PCI DSS 4.0 for Ecommerce: What Your Checkout Needs Now

For years, PCI DSS compliance for an online store felt like an annual formality: the acquirer sent a questionnaire, someone in IT filled it out, and the topic disappeared until the following year. If the store used a gateway with a hosted payment page or an iframe, the conclusion was almost always the same: "card data doesn't go through us, so almost nothing applies".

That has changed. E-skimming attacks —malicious code injected into the payment page that copies card data from the customer's browser before it ever reaches the gateway— grew enough for the PCI Security Standards Council, the body that maintains the standard, to tighten the rules on payment pages. Since March 31, 2025, the PCI DSS 4.0 requirements that force merchants to control every script running on checkout, and to watch for anyone tampering with it, are mandatory. In other words: even if the card never touches your server, your page can still be the way in.

At WolfSellers we implement and support Adobe Commerce (formerly Magento) stores in Mexico and for brands across North America, and checkout security is part of the scope of every project, not an appendix. This guide explains what PCI DSS is and who it applies to, what changed with version 4.0, the two requirements that change checkout, which self-assessment questionnaire applies depending on how you integrated your gateway, what Adobe Commerce solves out of the box and what is still on you.

A necessary caveat: this does not replace a Qualified Security Assessor (QSA) or your acquirer, who determine your level and how you validate compliance. Here we explain what the platform needs to support and how we implement it.

---

What PCI DSS is and who it applies to

PCI DSS (Payment Card Industry Data Security Standard) is the security standard the card brands define through the PCI Security Standards Council. It is not a law in Mexico, the US or Canada: it is a contractual obligation. Your acquirer —the bank or company that lets you accept cards— requires it because the networks require it of them.

It applies to any merchant that accepts card payments, even one that outsources all card handling to a gateway. What changes from case to case is not whether it applies, but how much of it applies and how you prove it:

• Merchant level. The brands classify merchants into levels by annual transaction volume. The largest validate with a Report on Compliance prepared by a QSA; the rest usually validate with a Self-Assessment Questionnaire (SAQ). Your acquirer tells you which level you are.
• Questionnaire type. There are several SAQs, and which one applies depends on how you capture the card. It is the technical decision with the biggest impact on your compliance burden, and we cover it below.

It also shouldn't be confused with personal data protection. PCI DSS protects card data; privacy law covers all of your customers' personal data. In Mexico that law is the LFPDPPP, and we explain it in our article on data protection for ecommerce in Mexico. They are separate obligations that run in parallel.

What changed with PCI DSS 4.0, and the dates that matter

PCI DSS 4.0 was published in 2022 with a long transition period: many new requirements were marked "future-dated", recommended but not mandatory, to allow time for implementation. That transition is over.

For an online store, the future-dated requirements that change the work the most are two: 6.4.3 and 11.6.1. Both attack the same problem, e-skimming, from two angles.

The two requirements that change checkout: 6.4.3 and 11.6.1

E-skimming works because a modern store's payment page loads many scripts: analytics, tag managers, chat, A/B testing, ad pixels, reviews. It only takes one of them being compromised —on your server or on a vendor's— for the attacker to read what the customer types. The two requirements close that door like this:

Two practical consequences worth understanding from the start:

1. The inventory is not a document, it's a process. Every time marketing adds a tag or a vendor updates its script, the inventory changes. Without an approval workflow, it goes stale within weeks.
2. The payment page is the one the customer sees, not the one in your repository. A script loaded through a tag manager doesn't appear in your code, but it does in the browser. That's why 11.6.1 requires reviewing the page as the browser receives it.

SAQ A, A-EP or D: which questionnaire applies to your integration

How you integrated your gateway decides how much of PCI DSS you have to prove. The general rule:

The January 2025 change to SAQ A deserves attention because it confused many teams. The PCI Security Standards Council removed requirements 6.4.3 and 11.6.1 from SAQ A (along with 12.3.1, the associated risk analysis), but added an eligibility criterion: the merchant must confirm its site is not susceptible to attacks from scripts that could affect its ecommerce systems.

In practice, according to the clarification the Council itself published, there are two ways to meet that criterion if you use an embedded payment form (an iframe):

1. Protect yourself, directly or through a third party, using techniques such as those in 6.4.3 and 11.6.1.
2. Get confirmation from your payment processor, if it is PCI DSS compliant, that its embedded solution includes protection against script attacks when implemented according to its instructions.

The criterion doesn't apply if you redirect the customer away from your site to pay, or if you fully outsource the payment function. The takeaway: "we use an iframe" no longer means "we don't have to do anything". Ask your provider for that confirmation in writing, or implement the controls.

What Adobe Commerce solves, and what's still on you

Adobe Commerce added controls designed for PCI DSS 4.0. Starting with version 2.4.7, according to its release notes:

• Content Security Policy (CSP) in restrict mode on payment pages. The default CSP configuration for storefront and Admin payment pages is now restrict, which blocks anything not on the allowlist; the rest of the site stays in report-only, which only reports. Before 2.4.7, every page was in report-only.
• A nonce provider to allow, in a controlled way, inline scripts the CSP would otherwise block.
• Subresource Integrity (SRI). Adobe Commerce generates integrity hashes for JavaScript files residing in the local filesystem, applied by default on payment pages. It does not cover remote third-party scripts, which remain your responsibility.

If your store runs Adobe Commerce on Adobe's cloud infrastructure, the shared responsibility model splits the work: Adobe maintains PCI certification for the platform's infrastructure and services, and the merchant is responsible for compliance of its customized application —its own code, extensions, third-party integrations— and its processes, including vulnerability scans by an Approved Scanning Vendor (ASV).

The most important warning: don't disable the CSP or SRI to "fix" a checkout that stopped working. When something breaks after enabling restrict mode, it's almost always a script nobody had inventoried. The fix is to decide whether that script belongs there and, if it does, to authorize it in the policy —not to turn the protection off.

The real problem: third-party scripts on the payment page

In the audits we run, the hard conversation is almost never about the store's code. It's about everything that got added to checkout over the years: a conversion tag from a campaign that already ended, a chat nobody uses at that step, a heatmap tool installed for a study two years ago.

Each of those scripts is a risk and a compliance to-do. The principle we apply is simple: the payment page should load only what is essential to take payment and measure conversion. Specifically:

1. Remove from checkout every script without a current justification. It's the cheapest control and the one that reduces risk the most.
2. Govern the tag manager. A tag manager lets people inject scripts without going through code. If it loads on the payment page, its publishes need an approval workflow, or those pages should be excluded from its scope.
3. Prefer a pinned version of each script when the vendor offers one, so its integrity can be assured with a hash; when none exists, restrict its origin through the CSP and cover it with 11.6.1 monitoring.
4. Give the inventory an owner, with a clear rule: nothing goes on the payment page without security approval.

Work plan: how to bring a checkout to PCI DSS 4.0

This is the order in which we work through it with our clients:

1. Map the payment pages. Checkout, payment steps, confirmation and any page where payment information is captured or displayed, including order creation in the Admin.
2. Inventory the scripts as the browser sees them, not just those in the repository, with their justification and owner.
3. Confirm the gateway integration and which questionnaire applies. If it's an iframe, request written confirmation of script protection or plan your own controls.
4. Bring Adobe Commerce to 2.4.7 or later, or plan equivalent work if the upgrade isn't immediate, and test restrict mode in staging before production.
5. Implement 11.6.1 monitoring, at least weekly, with alerts that reach someone able to act.
6. Close the operating loop: quarterly scans by an approved vendor, security patches kept current and a process so that every new script goes through approval.

Common mistakes

1. Assuming the gateway's iframe solves everything. Since March 2025 you need to demonstrate protection against scripts or hold the processor's confirmation.
2. Disabling the CSP to unblock checkout instead of authorizing the right script.
3. Inventorying only your own code and forgetting what the tag manager injects.
4. Treating the inventory as an annual document instead of a process with approvals.
5. Staying on unpatched versions. An outdated store is the most common door for script injection.
6. Confusing PCI DSS with personal data protection. They're separate obligations, and you need both.

How we do it at WolfSellers

When a client asks us to prepare their checkout for PCI DSS 4.0, we start with a diagnosis: payment pages, the real script inventory, the gateway integration type, the Adobe Commerce version and patch status. That produces a prioritized plan we implement with our cybersecurity team, and then sustain through support and maintenance: patches kept current, payment page monitoring and an approval process for every new script.

If you're also choosing or switching gateways, the way you integrate it defines a large part of your PCI scope. We explain it in our guide to payment gateways in Mexico. And if you'd like a review of your case, you can contact us.

---

Frequently asked questions about PCI DSS for ecommerce

Is PCI DSS compliance mandatory?

It isn't a law in Mexico, the US or Canada, but it is a contractual obligation for any merchant that accepts cards: acquirers require it because the card networks require it of them. The consequences of non-compliance are set by your acquirer contract and can range from fines to losing the ability to accept card payments, on top of the cost of an incident if data is stolen.

If I use my gateway's iframe, do I need to do anything for PCI DSS 4.0?

Yes. Under the SAQ A in effect since March 31, 2025, the merchant must confirm its site is not susceptible to script attacks. According to the PCI Security Standards Council, you can meet it by implementing techniques such as those in requirements 6.4.3 and 11.6.1, or with confirmation from your payment processor, if it is PCI DSS compliant, that its embedded solution includes that protection when implemented according to its instructions. The criterion doesn't apply if you redirect the customer away from your site to pay.

How often do payment page scripts need to be reviewed?

Requirement 11.6.1 calls for a change-detection mechanism that runs at least once a week, or at the frequency defined by a targeted risk analysis. In practice we recommend continuous automated monitoring with alerts, because a compromised script can steal cards for days before the next manual review.

Is Adobe Commerce on cloud already PCI DSS compliant?

The infrastructure is: Adobe maintains PCI certification for the platform's infrastructure and services. Your store isn't automatically certified, because compliance of your application —your own code, extensions, integrations and processes— remains the merchant's responsibility under Adobe's shared responsibility model.

Which Adobe Commerce version do I need for PCI DSS 4.0?

Starting with Adobe Commerce 2.4.7, payment pages use a Content Security Policy in restrict mode by default, plus Subresource Integrity for local JavaScript. On earlier versions, those controls have to be implemented another way. On any version, keeping security patches current and controlling third-party scripts remains essential.

Are PCI DSS and data privacy law the same thing?

No. PCI DSS is a card industry standard that protects payment data; privacy law —the LFPDPPP in Mexico— governs all the personal data a private company processes. An online store selling in Mexico has to comply with both, through controls that complement each other.

Related services

If this topic is relevant to your business, these services from WolfSellers can help you implement it:

• Adobe Commerce
• Adobe Commerce Implementation
• Cloud Infrastructure