Open source ecommerce for PCI DSS payment page requirements: what it asks of your store
If you run a self-hosted store, the first question is which self-assessment questionnaire your checkout falls under, because that answer decides whether requirements 6.4.3 and 11.6.1 apply to your payment pages directly. On SAQ D, both requirements apply in full. On SAQ A, they no longer appear as requirements. Instead, the PCI SSC removed them on 30 January 2025 and added an eligibility criterion: you must confirm your site is not susceptible to script attacks that could affect your e-commerce systems. Both requirements became mandatory on 31 March 2025, and PCI DSS v4.0.1 is the only active version of the standard, so that is the text your assessor will use.
The checkout design decides which path you are on. A store that hands card entry to a payment provider through a redirect or a provider-hosted frame may qualify for SAQ A, but only if every SAQ A criterion is met, including the script criterion. A store that serves its own card fields, or that loads third-party scripts onto the payment page without control, is likely to fall under SAQ D. Confirm the SAQ with your acquirer or payment brand before you change the checkout, since the PCI SSC does not enforce compliance or set penalties. The payment brands and acquirers decide who must validate and which questionnaire applies.
Before the next release, check three things: which scripts load on the cart and checkout pages, who authorized each one, and whether your change detection would catch an altered payment form in the browser. Ask your Magento partner to document each script with a written justification and an integrity method, and ask your hosting team how often change detection runs. Also confirm with your acquirer whether a self-hosted Magento Open Source store on your own infrastructure changes your scope. Any answer you cannot document is a finding for your assessor, so settle those questions in writing before the assessment window opens.
How checkout design decides which SAQ and which script controls apply
With a redirect, the shopper leaves the store for a page the provider hosts, so the card fields never render on the store's pages. A hosted payment page follows the same pattern with the provider's page styled to match the store. This design keeps account data out of the store's own pages, which is why it is the design most often associated with SAQ A. Eligibility still depends on meeting every SAQ A criterion, and the merchant must confirm the outcome with the acquirer.
- Likely SAQ path: Provider-hosted pages are the design most likely to fit SAQ A, provided every eligibility criterion is met and the acquirer agrees.
- Script criterion: Since 30 January 2025, SAQ A asks the merchant to confirm the site is not susceptible to script attacks that could affect the e-commerce systems. Requirements 6.4.3 and 11.6.1 were removed from SAQ A on that date.
- Scripts still on the page: Analytics, tag managers and advertising tags can still run on the store's checkout, so an inventory and tamper check remain sound practice even where the questionnaire no longer asks for them.
- Template hygiene: Confirm that no leftover custom payment block or legacy card field still renders on the Magento checkout.
- Return path: Test the return URL and order status update, because a broken return often leads teams to add custom code to the store.
Get the SAQ decision in writing from your acquirer and ask them to list the eligibility criteria they applied.
An iframe embeds the provider's card fields inside a frame on the store's checkout page. The shopper sees the store's address and layout, while the card data is entered into content served by the provider. The page that holds the frame still loads the store's HTML, scripts and styles, so it meets the glossary definition of a payment page: a web-based interface with form elements meant to capture account data. The store's own controls therefore remain in scope for script and change-detection questions.
- Payment page status: The checkout page that holds the frame is a payment page for the purposes of script management and change detection.
- Likely SAQ path: Iframe designs are often assessed on SAQ A where the criteria are met, but the store's page and scripts are part of the eligibility question, so confirm with the acquirer.
- Third-party scripts: Scripts the store loads on the checkout page, including any script the provider requires, need an authorization method and an integrity method where requirement 6.4.3 applies. The PCI SSC explains how third-party script providers fit into that picture.
- Frame controls: Ask the provider how the frame is locked down, including its source, its permitted parent origins and the content security policy it expects, and record the answers.
- Magento CSP: Magento supports Content Security Policy headers from 2.3.5, and from 2.4.7 restrict mode applies by default on payment pages. Confirm your release's behavior and test each allowed source.
Ask the provider for a written description of the frame's script behavior and file it with your script inventory.
In a direct post, the store's own form collects the card number on the store's page and sends the data to the provider's endpoint. The store's page and the browser handle the account data in transit, so the store's own form and its scripts sit in the card data path. This design generally moves the store away from the simplest questionnaire, so expect a questionnaire with more requirements. Provider-specific variants differ, so the acquirer must confirm which SAQ applies to the exact design.
- Likely SAQ path: Expect a questionnaire other than SAQ A, and confirm the exact type with the acquirer before design work starts.
- Full script controls: Requirement 6.4.3 applies to every script on the payment page, including analytics and tag managers. Each script needs an authorization method, an integrity method and a written justification in the inventory.
- Change detection: Requirement 11.6.1 expects a mechanism that alerts personnel to unauthorized changes to payment page contents as received by the consumer browser. It must run at least once every seven days or at a frequency set by a targeted risk analysis.
- Data path review: Document every server, log and cache that can see the card number, and confirm none of them store it.
- Serving infrastructure: Identify every host and CDN that delivers the form and its assets, because a change to any of them can alter what the browser receives.
Ask the acquirer which SAQ applies to this exact design and get the answer in writing before the build.
A card form built on Magento means the store collects the card data in its own templates, modules or custom checkout code. This design places the entire payment page under the store's control, so every payment page requirement applies in full. Expect the full questionnaire, SAQ D, and confirm the exact outcome with the acquirer, because the store's servers and code handle account data directly.
- Likely SAQ path: Self-built card collection usually falls under SAQ D, and the acquirer should confirm this in writing.
- Requirement scope: Requirement 6.4.2 requires an automated technical solution that detects and prevents web-based attacks and has been effective since 31 March 2025. It superseded 6.4.1, and 6.4.3 and 11.6.1 apply alongside it.
- Extension inventory: Each third-party Magento extension or theme that touches the checkout is a code and script source, so list it, justify it and track its updates.
- Content security policy: Use Magento's content security policy in restrict mode and test every allowed source, since the policy is the main technical control over which scripts can run.
- Upgrade effect: Each Magento patch can change checkout templates, so recheck the script inventory and the change detection baseline after every patch.
Get the ongoing evidence work scoped with your assessor before you commit to a self-built form, because that work recurs every assessment cycle.
Mapping 6.4.3 and 11.6.1 to what the Magento store must do
This table maps each relevant PCI DSS requirement to what the self-hosted Magento Open Source store has to do, how to configure the platform to support it, and what to confirm with your acquirer, QSA or script vendors. Read it as a checklist of questions to settle before you pick a checkout design, since the SAQ that applies depends on those answers. Note that Requirements 6.4.3 and 11.6.1 are listed in SAQ D, and their removal from SAQ A does not mean a store can ignore script risk.
| Requirement | What the function must do | How to configure Magento Open Source | What to confirm with the vendor or assessor |
|---|---|---|---|
| 6.4.3 authorized scripts | Keep a method to confirm each script on a payment page is authorized before it runs. | Limit scripts to a documented allowlist in the theme and tag manager. Use CSP restrict mode, which is the default on storefront and admin payment pages from 2.4.7, and define script-src sources explicitly. | Whether the assessor accepts CSP allowlists as the authorization method, and which SAQ your acquirer requires. |
| 6.4.3 script integrity | Assure each payment page script has not been altered, for example through subresource integrity or controlled hosting. | Self-host first-party scripts where possible. Where third-party scripts are unavoidable, apply integrity attributes and review changes in the deployment pipeline. | Whether your payment provider supplies scripts that the store can pin or hash, and how the provider handles updates. |
| 6.4.3 inventory and justification | Maintain a current inventory of every script on payment pages, each with a written business justification. | Export the active script list from the theme, extensions and tag manager, and record owner and purpose for each entry in a version-controlled register. | How the assessor expects the inventory to be evidenced, and whether extension-injected scripts must be listed. |
| 11.6.1 change and tamper detection | Detect unauthorized changes to security-impacting HTTP headers and to payment page contents as the consumer browser receives them. | Monitor response headers, including CSP, at the edge or with a browser-side monitoring tool. Varnish is the full-page cache for self-managed installs, so confirm header handling there. | Whether the monitoring runs in the consumer browser context and which headers and page elements the assessor considers in scope. |
| 11.6.1 check frequency | Run the detection mechanism at least once every seven days, or at a frequency set by a targeted risk analysis under 12.3.1. | Schedule automated checks and alerts, and record the frequency and any risk analysis that supports a longer interval. | Whether a targeted risk analysis is needed for your frequency, and who approves and documents it. |
| 6.4.2 automated attack prevention (supersedes 6.4.1) | Run an automated technical solution that continually detects and prevents web-based attacks, replacing the earlier 6.4.1 option. | Deploy a web application firewall or equivalent control in front of the store, and keep Magento and extension patches current on supported 2.4.x lines. | Whether 6.4.1 is reported as not applicable in your assessment, and what evidence of continuous operation the assessor expects. |
Which self-hosted platforms fit a PCI-scoped checkout
Each platform below can host a storefront, but the checkout design decides how much payment page code you own and how many scripts you must manage. The cards compare fit for payment page control, the main tradeoff, and the points to confirm with your payment provider and assessor before you commit.
Magento Open Source 2.4.9
Magento Open Source is licensed under OSL-3.0 and 2.4.9 is the latest stable tag. Its standard support runs to May 31, 2029, which matters for the planning window of a 6.4.3 script inventory and an 11.6.1 change detection program. Content Security Policy headers are supported from 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on payment pages. Tradeoff: the large module surface means every third-party script on checkout must be justified and inventoried. Confirm with your provider which checkout template you will use.
WooCommerce 11.2.1
WooCommerce is licensed under GPL version 2 or later and runs on WordPress, so the checkout page shares its theme and plugin layer with the rest of the site. That makes it simpler to host payment pages on a hosted provider's redirect or iframe flow, which keeps card data out of your environment. Tradeoff: every WordPress plugin that touches the checkout template adds scripts to the payment page. Confirm whether your payment plugin is maintained, which SAQ your acquirer assigns, and how plugin updates are tested before release.
Saleor 3.23.42 for headless checkout
Saleor is a headless commerce API licensed under BSD-3-Clause, and 3.23.42 was published on October 16, 2026. Because the storefront is a separate application, you decide where the checkout UI is built and hosted, which determines who controls each script. A payment provider's hosted fields or redirect keeps card entry off your servers. Tradeoff: the storefront, its build pipeline and its CDN become in-scope components that you must secure and monitor. Confirm with your assessor how the checkout app is scoped.
Medusa v2.21.2 for headless checkout
Medusa is MIT licensed except materials covered by its Enterprise Edition license, and v2.21.2 was published on September 28, 2026. Its modular architecture lets you separate the storefront checkout from the commerce backend, which supports a redirect or hosted payment flow without custom card forms. Tradeoff: the Enterprise Edition license boundary must be checked against the modules you plan to use, and the custom storefront adds a script inventory your team must maintain. Confirm which payment modules are maintained by the vendor and which need your own integration work.
Sylius v2.3.1 for custom checkout
Sylius is licensed under MIT and v2.3.1 was published on October 14, 2026. It is a Symfony-based framework, so teams that want full control of the checkout pages, including the payment step, can build and test that flow directly. Tradeoff: owning the checkout code means you also own the form elements that capture account data, which can move your validation toward a larger SAQ and a heavier 6.4.3 and 11.6.1 program. Confirm with your acquirer whether a hosted payment page is possible before choosing a custom build.
How Magento's CSP and cache layers help with 6.4.3 and 11.6.1
Magento's built-in Content Security Policy support is one of the few controls on a self-hosted store that can limit which scripts a browser will run on a payment page. Magento Open Source supports CSP headers from version 2.3.5, and from 2.4.7 the platform runs CSP in restrict mode by default on storefront and admin payment pages. That default matters for requirement 6.4.3, because a restrictive policy means an unlisted script is blocked rather than silently loaded. Your team still has to decide which sources belong in the policy, who approves each change, and how exceptions expire. Confirm with your developers which policy directives are set in your own configuration, and test the checkout after every module install, since a third-party tag that worked before can be blocked by a policy written for the previous set of scripts.
Varnish is the full-page cache for self-managed Magento installations, and it is a performance component, not a security control. It matters for the payment page audit trail in one practical way: cached HTML can serve a page that differs from what the origin server produced, so the team must know which pages are cacheable, which are excluded, and how cache purges are logged. Confirm with your hosting team whether checkout and payment pages bypass the cache and whether purge events are retained. Cloud-hosted Adobe Commerce uses Fastly instead, so a hosting decision changes which cache configuration you must document.
CSP and caching do not produce the evidence that requirements 6.4.3 and 11.6.1 call for. Requirement 6.4.3 needs a confirmed list of authorized scripts, a method to verify their integrity, and a written justification for each script. Requirement 11.6.1 needs a change- and tamper-detection mechanism that checks the payment page as the consumer's browser receives it, at least every seven days or at a frequency set by a targeted risk analysis. A policy header tells you what the browser is allowed to load; it does not tell you whether a script was altered or whether a new one appeared. Plan a separate script inventory, an integrity method, and a page monitoring tool, and keep their records alongside your policy and cache configuration as the evidence an assessor will ask for.
Evidence assessors ask for on payment page scripts and change detection
This table lists the records an assessor typically asks to see for script management under 6.4.3 and change detection under 11.6.1, what each record proves, and which part of the stack usually produces it. Use it to design logging before the assessment starts, not to reconstruct records afterward. Confirm with your acquirer or payment brand which SAQ applies, since the required evidence depends on that answer.
| Evidence item | What it proves | Component that produces it |
|---|---|---|
| Script inventory with written justifications | Every script on payment pages is known, and each one has a documented business reason to be there (6.4.3) | Tag manager export, theme and module manifests, CSP reports cross-checked against the list |
| Authorization record per script | Each script was approved by a named owner before it went live, not added silently by a developer or extension | Ticketing approvals linked to each inventory entry, change approval records |
| Integrity method records | Scripts are protected by a documented integrity check, such as subresource integrity or a hash-based control, and the method is applied consistently (6.4.3) | Deployment pipeline logs, build artifacts with hashes, SRI attributes in template output |
| Change detection alert logs | The 11.6.1 mechanism detects unauthorized changes to payment page content and security-impacting HTTP headers as the browser receives them | File integrity or browser-side monitoring tool alert history, SIEM or alerting platform records |
| Change detection review records at the 11.6.1 frequency | Alerts are triaged and the mechanism ran at least every seven days or at the frequency set by the targeted risk analysis | Ticketing system entries, on-call or SOC review logs, scheduled job records for the monitoring tool |
| CSP reports and header configuration | Content Security Policy is deployed on payment pages and violations are captured and reviewed | Web server or storefront CSP configuration, browser violation report collection, review tickets |
| ASV scan results where SAQ A applies (FAQ 1604) | External vulnerability scanning by an Approved Scanning Vendor was completed and passing results are on file for the relevant scope | ASV scan reports from the scanning vendor, scan scope documentation |
| Third-party script provider documentation (FAQ 1592) | Providers that supply scripts on the payment page are identified, and their responsibilities and contracts are on file | Vendor contracts, provider list, responsibility matrix, their AOC or attestation where available |
| Attestation of Compliance or Report on Compliance | The formal validation result for the chosen SAQ or ROC, signed by the merchant and, where required, the assessor | Completed PCI SSC template (SAQ with AOC, or ROC prepared by a Qualified Security Assessor) |
What tooling alone does not satisfy
Scripts, headers and change detection each produce evidence, but none of them decides the outcome on its own. The cards below cover the points where a self-hosted Magento Open Source store still depends on the merchant's own decisions, records and operating routines.
A CSP header does not prove authorization
Magento Open Source can send Content Security Policy headers, and from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages. A restricted policy limits where scripts may load from, but it does not show that each script on the page was approved, justified or verified. Requirement 6.4.3 still needs a method to confirm authorization, an integrity check and a written inventory with justification for every script. Check whether your team keeps that inventory for each extension, theme change and tag manager container.
Change detection without owned alerts
Requirement 11.6.1 expects a tamper-detection mechanism that alerts personnel to unauthorized changes to payment page contents as the consumer's browser receives them. A monitoring tool that writes to a dashboard nobody watches misses the intent of that requirement. Name the on-call owner, the response time and the escalation path for each alert. Confirm that a change to a checkout script at 2 a.m. reaches someone who can disable it, and test that path before the assessment.
SAQ A depends on your own confirmation
SAQ A requires that all of its eligibility criteria are met, and one of them is the merchant's confirmation that its site is not susceptible to script attacks that could affect its e-commerce systems. That is an attestation about your environment, not a fact a plugin can supply. Before signing, review the checkout, every third-party script and each Magento extension with your acquirer or payment brand, and record the reasoning. A tooling report alone does not support that confirmation.
The SAQ choice and scope remain yours
The PCI SSC does not decide which self-assessment questionnaire applies to you. Your acquirer or payment brand does, and scope changes with how the checkout is built, including whether card data touches your servers. Self-hosting adds responsibility for the web server, the Magento application, the database and any reverse proxy or cache in front of them. Ask your partner to map each component to a scope decision in writing, and to flag any change that could move the store into a different questionnaire.
Third-party script providers stay in scope
Payment providers, fraud tools, analytics tags and chat widgets each load code into the page, and each one can change without notice. PCI SSC guidance on third-party script providers means you still need to know which parties can alter what the shopper sees. Keep a contract list for each provider, the script URLs they serve and the person who approves updates. Without that register, the inventory required by 6.4.3 will be incomplete the first time a marketing team adds a tag.
Questions buyers ask before hiring help on PCI DSS payment pages
How much does PCI DSS payment page work add to a Magento build?
The cost depends on how many scripts, providers and checkout paths the store runs, so no single figure applies to every store. Work is usually split into a one-time part (scoping the checkout, building the script inventory, setting up authorization and integrity checks, configuring change detection and testing) and a recurring part (reviewing new scripts, reviewing alerts, patching and re-validating after upgrades). The main drivers are the number of third-party scripts, whether the checkout is a hosted redirect or a custom payment form, how many payment providers are connected, and whether the Magento host also serves the checkout. Ask for a written scope that lists each of these items separately, with the deliverables and the party responsible for each. DeployOpen works on fixed scope agreed in writing before work starts, and quotes follow from that scope.
How long does a PCI DSS payment page project take?
No duration figure applies here because the timeline depends on the store's current checkout, script count and hosting setup. The most useful step is to ask for a written plan that states phases, dependencies on the acquirer's answers, the access the team needs, and the dates each deliverable is due. Ask which tasks can start before the acquirer confirms the SAQ, and which must wait. Also ask how the plan handles a store that already runs several marketing and analytics tags, because removing or re-approving them is often the longest step. DeployOpen agrees timelines in the written scope before work begins.
What does the merchant need to provide for a PCI DSS scope review?
The merchant needs to provide four groups of input before the work can be scoped accurately:
- A current inventory of every script and tag that loads on checkout and payment pages, including tag manager containers and their owners.
- Written answers from the acquirer or payment brand on which SAQ applies, since the merchant must confirm this with them (see PCI SSC FAQ 1215 for background).
- Access to the hosting environment, Magento admin, deployment pipeline and web server or CDN configuration.
- Contracts or documentation from each payment and script provider, including what they load and how they change it.
Ask the implementation partner to confirm in writing which of these items it expects from you and which it will produce itself.
Can our own team handle PCI DSS script management and change detection?
Yes, a capable internal team can run these controls, but it needs to own the tasks that PCI DSS places on the merchant. Those include keeping the script inventory current, documenting a written justification for each script, confirming each script's authorization and integrity, and reviewing the output of change detection. The team also needs to decide who answers alerts and how fast. Teams that lack Magento, web security and payment page experience usually benefit from an outside review of the design before they run it. DeployOpen can plan, implement, harden and document these controls, and can also support the team after handover through a retainer if the scope calls for it.
Does DeployOpen issue the PCI DSS Attestation of Compliance?
No. DeployOpen does not issue audit reports, attestations or certifications. It prepares systems, controls and evidence for a compliance assessment, and the Attestation of Compliance comes from the merchant and its validating party, following the official PCI SSC template. PCI SSC FAQ 1220 also states that certificates are not recognized as validation, so a vendor certificate should not be accepted as proof of compliance. Ask any partner to show which evidence it will hand over, and which parts the merchant or its assessor must sign or produce.
Who is the Qualified Security Assessor, and do we need one?
A Qualified Security Assessor is only needed when the merchant's assessment is a Report on Compliance (ROC). A Self-Assessment Questionnaire (SAQ) does not require a QSA, and the merchant completes it with its own team and signs the Attestation of Compliance. Whether a ROC applies depends on the merchant's volume and the rules of its acquirer or payment brand, so confirm that with them first. If a ROC applies, the QSA is selected and paid by the merchant, and it must be independent of the team that built the store. Ask the implementation partner to explain how its evidence will be provided to the QSA.
What does the implementation partner need to access on our store?
The partner needs enough access to review the checkout, scripts, headers and hosting, but not more than that. Typical access includes read access to the Magento admin and configuration, the code repository, the deployment pipeline, the web server or CDN settings and the change-detection tooling. Ask for named accounts, a time-limited access model, and a record of who changed what. Ask also whether production secrets, card-data systems or payment provider credentials are in scope, and how the partner will handle them. DeployOpen works inside the client's own infrastructure, so access is granted and revoked by the client.
What to confirm with your acquirer before you choose the checkout
Start with the question that decides everything else: which Self-Assessment Questionnaire applies to your store. The acquirer or payment brand confirms this, not the platform vendor or the implementation partner. All eligibility criteria of SAQ A must be met before that questionnaire can be used, and PCI SSC guidance tells merchants to confirm the applicable SAQ with their acquirer or payment brand. Ask for the answer in writing, with the SAQ version and the date it was confirmed, because the checkout design you choose later has to match it.
Next, ask the acquirer to confirm the payment page model in your exact checkout flow. Ask whether the provider's hosted page or iframe is the only page that collects account data, and whether any Magento Open Source custom checkout module, third-party extension or theme script also touches a form that could capture card data. Ask how the acquirer treats scripts loaded on the cart and checkout pages, including analytics, tag managers and fraud tools, because a script that can read the payment fields can change the answer. Document each answer against the list of scripts you will maintain under Requirement 6.4.3.
Then ask two eligibility questions that depend on your own environment. For the SAQ A script criterion, ask how the acquirer expects you to show that your site is not susceptible to script attacks that could affect the e-commerce systems, and what evidence it accepts. For external scanning, ask whether an Approved Scanning Vendor scan of the internet-facing store is required under your chosen SAQ, and which hosts, IP addresses and load balancers it should cover. Record the answers, the evidence each one requires and the owner on your side, so the checkout decision can be tested against them before the first release.
How a 6.4.3 and 11.6.1 rollout on Magento runs
The sequence turns script management and payment page change detection into a documented, repeatable control set that an acquirer or assessor can review. It starts with confirming which SAQ applies and ends with evidence packaged for the assessor. Ask for a written schedule before work starts, because no durations are fixed here.
Confirm the SAQ with the acquirer
Before any technical change, confirm with your acquirer or payment brand which self-assessment questionnaire applies to your checkout design. SAQ A requires that all of its eligibility criteria are met, including the criterion that the site is not susceptible to script attacks that could affect its e-commerce systems. Your team and DeployOpen agree in writing which SAQ is the target. The step is done when the SAQ and its scope boundary are recorded in the project file.
Inventory every script and tag
Crawl the storefront, checkout and admin payment pages in a staging copy, then list every script, tag, pixel and iframe loaded in the browser, including those added by extensions, tag managers and third-party providers. Record the owner, the source URL, the business reason and a written justification for each item. The step closes with an approved inventory that the payment and marketing owners have signed off, with unjustified scripts removed or flagged for decision.
Set Content Security Policy and script authorization
Configure Content Security Policy headers in Magento Open Source so that only the approved script sources are allowed to run on payment pages, and set a method that confirms each script is authorized before it is added. Test the policy in report mode first, because a strict policy can break checkout if an approved source is missing. The step is done when the policy, the authorization procedure and a test log show that unlisted scripts are blocked on the checkout path.
Deploy script integrity and change detection
Add subresource integrity or an equivalent method to each approved script, and deploy a change- and tamper-detection mechanism that monitors security-impacting HTTP headers and payment page contents as they arrive in the consumer browser. The mechanism must run at least once every seven days or at a frequency set by a targeted risk analysis. Confirm with your assessor which approach is acceptable for your checkout. The step is done when a test modification triggers an alert in the monitoring console.
Define alert handling and review frequency
Write the procedure for who receives each alert, how it is triaged, how an unauthorized change is rolled back or investigated, and how the team decides whether a script change is legitimate. Set the review frequency, either the seven-day cycle or a documented risk-based interval. The owner for each role is named. The step closes when a tabletop exercise with a simulated skimming alert has been run and the timings and decisions are recorded.
Collect and retain the evidence
Gather the approved inventory, written justifications, authorization records, CSP configuration history, integrity and change-detection logs, alert tickets and the review records for a period your assessor specifies. Store them in a location the assessment team can access, and keep a dated change log for each script update. The step is done when an internal reviewer can trace one script from its justification to its latest monitoring result without help from the implementation team.
Hand the evidence to the assessor
Provide the evidence package to your acquirer, payment brand or Qualified Security Assessor, and walk them through the scope, the SAQ selection and the control operation. Ask for their findings in writing and track each follow-up item to closure. DeployOpen prepares the systems, controls and evidence for the assessment, but the assessor issues the findings, and the merchant completes the Attestation of Compliance. The step closes when the assessor's written findings are recorded and any remediation is scheduled.
How DeployOpen scopes and supports payment page controls
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Magento Open Source store, that means the work covers the storefront servers, the checkout integration, the script inventory and the change-detection tooling in your environment, not in a hosted service we operate on your behalf. DeployOpen also runs security testing of the storefront, its APIs and its hosting, and prepares the systems, controls and evidence that an assessor will ask for. We do not issue Reports on Compliance, Self-Assessment Questionnaires, Attestations of Compliance or any other validation. Your acquirer or payment brand confirms which SAQ applies, and a Qualified Security Assessor or the appropriate assessment process reaches the conclusion.
Most engagements are fixed-scope, so the written agreement should name the checkout design you are implementing, the SAQ you expect to validate against, the scripts in scope, the monitoring tool, the alert recipients and the evidence package. Ask for each deliverable to be listed with an acceptance step, and ask how changes to scope are priced before work starts. Quotes should separate one-time work, such as the initial script inventory and hardening, from recurring work, such as weekly change-detection review, patch application and re-testing after each release. DeployOpen does not publish a price list, so the quote follows from that written scope.
Payment page controls do not stay correct on their own. Scripts change when marketing tags are added, when extensions are updated and when a third party changes its own code, so ongoing support matters as much as the first build. A retainer can cover recurring testing of the checkout, review of alerts from the change-detection mechanism, script inventory upkeep and upgrades of Magento Open Source and its extensions. Confirm in writing who owns each of these tasks: your team, DeployOpen, your hosting provider or the extension vendor.
