PCI DSS v4.0 made every mid-market merchant who had been quietly running a custom checkout reconsider their compliance posture. The new requirements around client-side script integrity, expanded vulnerability management, and tighter authentication controls landed during an already-busy compliance year, and the response from many brands was to assume that achieving compliance meant replatforming. It usually does not. This composite case study, drawn from work patterns we see across mid-market Magento merchants, walks through how a $30 to $50 million annual revenue Magento merchant moved from a v3.2.1 SAQ D-Merchant posture to a clean v4.0 SAQ A-EP posture without changing platforms.
The names and exact numbers are anonymized. The decisions and the architectural moves are typical of what actually works in practice. The merchant in this case was running Adobe Commerce 2.4 on AWS with a custom checkout that handled card data through a tokenized iframe but rendered the iframe inside a checkout page that also loaded analytics, marketing, and personalization scripts. That mix is what made compliance harder than it needed to be.
Starting Posture and the Gap Assessment
The first move in any v4.0 effort is an honest gap assessment. The merchant’s previous QSA had accepted the v3.2.1 posture because the iframe approach kept the merchant out of card data scope, but v4.0 explicitly tightens requirements around scripts loaded on pages that include payment functionality. Per the PCI Security Standards Council, the v4.0 requirements 6.4.3 and 11.6.1 require merchants to inventory, justify, and continuously verify integrity of scripts on payment pages.
The gap assessment surfaced six material findings:
The merchant qualified for SAQ A-EP rather than SAQ A because the payment page was hosted on the merchant’s own domain. The team had been treating it as SAQ A, which was incorrect under v4.0.
There was no inventory of scripts loaded on the checkout page. Marketing tags had accumulated through Tag Manager over years, and nobody could account for what each one did.
There was no Content Security Policy, and no Subresource Integrity hashes on third-party scripts. Both are now expected controls under v4.0.
The vulnerability management cadence was quarterly. v4.0 expects more frequent scanning for high-risk components, with internal vulnerability scans at least every three months and authenticated scanning of internet-facing systems.
Log retention was 90 days. v4.0 requires at least 12 months, with three months immediately available.
The third-party script governance process was informal. Marketing could add tags through GTM without security review.
None of these required replatforming. All of them required disciplined remediation work over a roughly 90-day window.
SAQ Tier Selection and What It Actually Means
The most important decision in any merchant’s PCI journey is determining the correct SAQ tier, because the tier determines how much of the merchant’s environment falls into compliance scope. The wrong tier is the most common reason small remediation projects turn into unplanned replatforming projects.
| SAQ type | When it applies | Compliance burden |
|---|---|---|
| SAQ A | Card data fully outsourced; payment page hosted entirely by a PCI DSS validated third party (full redirect) | Smallest scope; minimal merchant infrastructure controls required |
| SAQ A-EP | Merchant website manages elements of the payment page even if card data is processed by a third party (iframe on merchant page, hosted fields embedded on merchant page) | Moderate; merchant environment is partially in scope; v4.0 script controls fully apply |
| SAQ D-Merchant | Merchant stores, processes, or transmits card data, including custom checkout that handles PAN even briefly | Largest scope; full DSS applies including network segmentation, log monitoring, vulnerability management |
| SAQ P2PE | Merchant uses validated point-to-point encryption with PCI-listed solution | Reduced scope but only for in-person; not applicable to most pure eCommerce merchants |
For this merchant, moving from SAQ D-Merchant to SAQ A-EP was the highest-leverage compliance decision. It meant ensuring that no card data ever touched merchant infrastructure, even transiently, by switching to a properly hosted payment field model. Adobe Commerce supports several payment integration patterns, and the Adobe Commerce security documentation details which integration models qualify for which SAQ tier. Choosing the right one was the difference between a 90-day remediation and a year-long compliance project.
Hosted Payment Fields vs Iframe vs On-Page Tokenization
The three common payment integration patterns each carry different SAQ implications, and this is where merchants most often misjudge their compliance burden.
Full redirect to a hosted payment page keeps the merchant in SAQ A. The payment page is served entirely by the payment service provider on their domain. The merchant never sees card data and bears no script integrity obligation around the payment fields themselves. The trade-off is checkout experience: the customer leaves the merchant domain.
Iframe payment fields put the merchant in SAQ A-EP territory in most cases. The iframe is served by the PSP, but it is loaded inside a merchant-controlled page. The card data does not touch merchant infrastructure, but the merchant page that hosts the iframe is in scope for the v4.0 script governance requirements.
Hosted payment fields and on-page tokenization can be either A-EP or D-Merchant depending on implementation. If the payment fields are JavaScript widgets served from the PSP that tokenize at the browser before any card data reaches the merchant origin, the merchant is in A-EP. If the merchant’s checkout JavaScript ever has access to the PAN, even in memory, the merchant is in D-Merchant.
The case study merchant moved from a hybrid model with custom checkout JavaScript that briefly handled card details to a clean hosted payment field implementation where tokenization happened inside PSP-served iframes. This single change pulled the entire checkout out of D-Merchant scope.
CSP and SRI Implementation Under v4.0
PCI DSS v4.0 requirement 6.4.3 expects merchants to inventory and authorize all scripts loaded on payment pages. Requirement 11.6.1 expects merchants to detect unauthorized changes to scripts on payment pages. The practical implementation pattern that satisfies both is a combination of Content Security Policy and Subresource Integrity, supplemented by either runtime tamper detection or a managed PCI client-side security service.
For the case study merchant, the CSP rollout took roughly six weeks. The first phase was monitoring mode, where every script load was logged but nothing was blocked. This surfaced the actual inventory of scripts running on production checkout, which turned out to be 23 distinct sources, four of which the team could not identify the business owner for. After audit, six tags were retired entirely, three were moved to non-checkout pages, and the remaining 14 were placed on an explicit allowlist with SRI hashes where possible.
The Bemeir team supports merchants through this exact pattern regularly, because it is one of the most error-prone parts of v4.0 work. A misconfigured CSP can break checkout in subtle ways, and validating across mobile browsers, desktop browsers, and the long tail of device types takes meaningful time. Resources from OWASP on CSP and SRI implementation, and the threat modeling guidance from NIST, are the references the security team relied on throughout this phase.
Vulnerability Management Cadence and Log Retention
The merchant’s vulnerability management cadence moved from quarterly external scans to a structured schedule: weekly authenticated scanning of internet-facing systems, monthly internal vulnerability scans, and quarterly penetration testing for any environment with payment functionality. Critical vulnerabilities were tracked with a 30-day remediation SLA, high-severity with 60 days, and medium-severity with 90 days, aligned with v4.0 expectations.
Log retention moved from 90 days to 13 months, with the most recent 90 days kept hot for immediate query and the older logs in cold storage with retrieval within 24 hours. This required infrastructure work on the AWS side: a CloudWatch and S3 lifecycle policy that handled the tiering, plus a SIEM integration that allowed the security team to query historical events without restoring entire log archives.
The Bemeir Magento engineering team does this kind of infrastructure tuning routinely, because the AWS configuration that supports compliant log retention is the same infrastructure that supports performance and reliability for Magento merchants generally. There is no separate compliance-only infrastructure on a well-architected AWS deployment.
Third-Party Script Governance
The lasting change at the merchant was the script governance process. Marketing could no longer add a tag through GTM without security review. The new workflow required every new script to go through a lightweight review (15 to 30 minutes typically) that documented the business owner, the data the script accessed, the load location (checkout vs other pages), and the SRI hash or alternative integrity control. This sounds bureaucratic but it added roughly two days to typical tag deployments, which was acceptable to the marketing team once they understood the alternative.
The final compliance posture was clean SAQ A-EP, attested by the merchant’s QSA, with documented controls for every v4.0 requirement that applied. No replatforming was required. No major Magento customization had to be rebuilt.
What This Tells Other Mid-Market Magento Merchants
The pattern is consistent across the merchants we work with. PCI DSS v4.0 compliance is achievable on Adobe Commerce without changing platforms. The work that matters is at three layers: the SAQ tier you actually qualify for given your checkout architecture, the script governance posture you maintain on your payment pages, and the operational discipline around vulnerability management and log retention.
Replatforming is rarely the right answer for compliance alone. It is sometimes the right answer for compliance plus performance plus a redesign that the brand was already planning, where compliance is one of several drivers, and in those cases Bemeir often pairs the v4.0 work with a Hyvä frontend rebuild so the merchant exits the year with a faster site as well as a clea
