Payment-page scripts
Scripts loaded in the consumer’s browser must be authorised, integrity-checked and inventoried when the requirement applies.
Payment security, without vague promises
DX3 provides a PCI DSS v4.0.1-aligned hosting service and the evidence behind it. Your store, payment integration and validation remain a shared-responsibility exercise—and this page shows where the lines sit.
Current guidance
PCI DSS v4.0.1 is the current standard. The requirements previously described as “future dated” became effective on 31 March 2025 and must now be considered in an assessment where applicable.
Scripts loaded in the consumer’s browser must be authorised, integrity-checked and inventoried when the requirement applies.
Payment pages and security-impacting HTTP headers require a mechanism that detects unauthorised changes, at least weekly or at a risk-defined frequency.
PCI DSS scope must be documented and confirmed at least annually—and again after a significant change.
Using a provider reduces what you operate; it does not remove your duty to document, monitor and understand the provider relationship.
Your checkout changes the answer
The right SAQ and control set depends on the real payment flow—not the name of a plugin. Confirm the route with your acquirer, payment brand or qualified assessor.
The customer leaves your site for a validated provider’s hosted payment page. This commonly offers the smallest ecommerce scope, provided every eligibility condition is met.
Payment elements originate from the provider but appear in your page. SAQ A may still be possible, but the merchant must now confirm its site is not susceptible to script attacks affecting the ecommerce system.
If your server, application or browser-delivered code stores, processes or transmits account data, the scope is materially broader. Obtain specialist advice before deployment.
Contractual allocation
This is the same matrix published in our Terms of Service. It identifies the stated allocation at control level; your actual applicability still depends on your environment and payment flow.
| PCI DSS | Control area | DX3webs | Client | Shared | Responsibility boundary / notes |
|---|---|---|---|---|---|
| 1.1 | Roles, responsibilities and operating procedures for network security controls | ✓ | DX3 documents and operates infrastructure/network responsibilities; client documents its own network and application-security responsibilities. | ||
| 1.2 | Configuration and change control for network security controls | ✓ | DX3 manages host firewall/network security controls for managed systems. Client manages controls outside the contracted DX3 layer, including customer-managed edge/CDN services. | ||
| 1.3 | Restrict network access between trusted and untrusted networks | ✓ | DX3 restricts traffic to managed servers and service ports. Client is responsible for external networks and application-side exposure it controls. | ||
| 1.4 | Control connections between trusted and untrusted networks | ✓ | DX3 applies managed-server ingress/egress restrictions. Client controls its own connected networks and services. | ||
| 1.5 | Controls for computing devices that connect to both untrusted networks and the CDE | ✓ | DX3 controls DX3 administrative access endpoints and methods; client controls merchant endpoints and users. | ||
| 2.1 | Secure-configuration roles and operating procedures | ✓ | Each party documents and operates secure configuration responsibilities for components it manages. | ||
| 2.2 | Secure configuration of system components | ✓ | DX3: Ubuntu/Plesk/web/database/cache/search services and managed infrastructure. Client: Magento/WooCommerce/custom application and customer-managed software. | ||
| 2.3 | Wireless environment controls | ✓ | No wireless network is part of the standard DX3 managed-server CDE. Client remains responsible for any wireless environment within its own PCI scope. | ||
| 3.1 | Account-data protection processes and responsibilities | ✓ | DX3 maintains a zero-intentional-storage position for CHD/SAD and controls accidental storage. Client owns merchant data-handling requirements. | ||
| 3.2 | Account-data retention and disposal | ✓ | DX3 does not intentionally retain CHD and performs retention/disposal controls for managed infrastructure. Client defines and enforces any merchant retention outside DX3. | ||
| 3.3 | Sensitive authentication data is not stored after authorisation | ✓ | Storage is prohibited on DX3 systems; client and its PSP remain responsible for payment-processing behaviour and application configuration. | ||
| 3.4 | Restrict display of PAN | ✓ | DX3 does not intentionally receive PAN. Any permitted PAN display is a merchant/payment-application responsibility. | ||
| 3.5 | Render stored PAN unreadable | ✓ | Standard DX3 service does not intentionally store PAN. If a customer introduces PAN storage, it is outside the standard service model and must be separately scoped and agreed. | ||
| 3.6 | Protect cryptographic keys used for stored account data | ✓ | No DX3-managed stored-PAN key-management service is included in the standard hosting service. | ||
| 3.7 | Key-management lifecycle for stored account data | ✓ | Customer/payment provider responsibility unless separately contracted and scoped. | ||
| 4.1 | Transmission-security policies and responsibilities | ✓ | DX3 manages secure transport configuration for managed hosting endpoints; client manages application/payment-provider configuration. | ||
| 4.2 | Protect PAN during transmission over open/public networks | ✓ | DX3 manages TLS on managed hosting endpoints. Client/PSP is responsible for the payment flow and any CHD transmission beyond the DX3 hosting layer. | ||
| 5.1 | Malware-protection policies and responsibilities | ✓ | Each party covers components under its control. | ||
| 5.2 | Prevent or detect malware on system components | ✓ | DX3 applies server/infrastructure protections and monitoring; client remains responsible for application content, extensions and endpoints it manages. | ||
| 5.3 | Maintain and operate anti-malware mechanisms | ✓ | DX3 for managed infrastructure; client for its application/endpoints where applicable. | ||
| 5.4 | Anti-phishing controls for personnel | ✓ | DX3 protects and trains its personnel; client protects and trains its own personnel. | ||
| 6.1 | Secure-systems/software policies and responsibilities | ✓ | Each party documents responsibilities for systems/software it manages. | ||
| 6.2 | Bespoke/custom software development security | ✓ | Customer/development agency responsibility. Standard DX3 managed hosting does not include ownership of merchant application development. | ||
| 6.3.1 | Identify and risk-rank security vulnerabilities | ✓ | DX3 monitors vulnerabilities affecting managed OS/services/infrastructure. Client monitors Magento/WooCommerce/custom code and extensions it owns. | ||
| 6.3.2 | Maintain inventory of bespoke/custom and third-party software components | ✓ | DX3 maintains managed platform component inventory; client maintains application/module/library inventory. | ||
| 6.3.3 | Install applicable security patches/updates | ✓ | DX3 patches managed OS/Plesk/services. Client patches Magento/WooCommerce/custom application/components unless a separate application-management service applies. | ||
| 6.4.1 | Protect public-facing web applications from attacks | ✓ | DX3 provides server-side security controls such as ModSecurity/WAF where included; client is responsible for secure application code and configuration. | ||
| 6.4.2 | Automated technical solution for public-facing web applications | ✓ | DX3 operates managed WAF controls where included in service. Client remains responsible for application security and any customer-managed WAF/CDN layer. | ||
| 6.4.3 | Manage payment-page scripts | ✓ | Payment-page/payment-integration responsibility remains with the merchant and payment provider. DX3 may provide supporting CSP/client-side controls where specifically included. | ||
| 6.5 | Change management for system components | ✓ | DX3 controls changes to managed infrastructure; client controls merchant application/code/configuration changes. | ||
| 7.1 | Access-control policies and responsibilities | ✓ | DX3 for hosting-platform access; client for merchant application/business-system access. | ||
| 7.2 | Define and review access by business need and least privilege | ✓ | DX3 reviews DX3 administrative access; client reviews Magento/WooCommerce/CMS/business-user access. | ||
| 7.3 | Access-control systems enforce assigned privileges | ✓ | DX3 enforces infrastructure privileges; client enforces application privileges. | ||
| 8.1 | Identity/authentication policies and responsibilities | ✓ | Each party manages identities within its control. | ||
| 8.2.1 | Unique identification of users | ✓ | DX3 uses unique IDs for managed-platform administration; client uses unique IDs for merchant application users. | ||
| 8.2.2 | Control shared/group/generic accounts | ✓ | DX3 prohibits shared administration accounts except formally controlled exceptional cases; client must do the same for its users. | ||
| 8.2.5 | Terminate/revoke access promptly when no longer required | ✓ | DX3 revokes DX3 personnel access; client revokes merchant/application personnel access. | ||
| 8.3.1 | Use strong authentication for users and administrators | ✓ | DX3 for managed systems; client for its systems/applications. | ||
| 8.3.5 | Unique initial/reset credentials and first-use change | ✓ | DX3 applies this to managed-platform accounts where technically applicable; client applies it to merchant/application accounts. | ||
| 8.3.6 | Password/passphrase minimum length and complexity | ✓ | DX3 policy requires current PCI-aligned password controls for managed systems; client is responsible for its application policy/settings. | ||
| 8.3.7 | Prevent reuse of recent passwords | ✓ | DX3 for managed systems where password authentication is used; client for its own systems. | ||
| 8.3.9 | Password changes or dynamic security posture where applicable | ✓ | Each party implements the applicable PCI DSS authentication approach for systems it controls. | ||
| 8.4 | Multi-factor authentication | ✓ | DX3 applies MFA to applicable managed administrative access; client applies MFA to applicable merchant/application access. | ||
| 8.5 | MFA system configuration and independence | ✓ | Each party is responsible for the MFA implementation it operates. | ||
| 8.6 | Application/system accounts and authentication factors | ✓ | DX3 manages service/system accounts in managed infrastructure; client manages application/system accounts it creates. | ||
| 9.1 | Physical-security policies and responsibilities | ✓ | DX3 manages its physical-security/TPSP obligations for hosting facilities; client manages its own offices, media and physical environments. | ||
| 9.2 | Physical access to systems in the CDE | ✓ | DX3/upstream data-centre provider controls physical access to hosted infrastructure; client controls physical access in its own locations. | ||
| 9.3 | Authorise/manage personnel and visitor physical access | ✓ | Applied separately by DX3/upstream facility provider and by client to their own locations. | ||
| 9.4 | Media storage, access and destruction | ✓ | DX3 for media/backups it controls; client for merchant-owned media and records. | ||
| 9.5 | Point-of-interaction device protection | ✓ | No card-present POI devices form part of the standard DX3 managed-hosting service. | ||
| 10.1 | Logging/monitoring policies and responsibilities | ✓ | DX3 for managed infrastructure; client for application/business logs. | ||
| 10.2 | Generate audit logs for relevant system events | ✓ | DX3 generates infrastructure/security logs; client ensures required merchant application events are logged. | ||
| 10.3 | Protect audit logs from unauthorised modification | ✓ | Each party protects logs under its control. | ||
| 10.4 | Review security logs and events | ✓ | DX3 reviews managed infrastructure/security alerts; client reviews application/business events under its control. | ||
| 10.5 | Retain audit-log history | ✓ | DX3 retains applicable managed-platform security logs in line with policy; client retains required application/business logs. | ||
| 10.6 | Time synchronisation | ✓ | DX3 maintains time sync for managed servers; client manages systems outside DX3 control. | ||
| 10.7 | Detect/respond to failures of critical security controls | ✓ | DX3 for managed monitoring/security controls; client for application controls and merchant systems. | ||
| 11.1 | Security-testing policies and responsibilities | ✓ | Testing responsibilities follow ownership of the system/component being tested. | ||
| 11.2 | Wireless access-point detection | ✓ | No wireless environment is part of the standard DX3 managed hosting platform; client handles any wireless environment in its PCI scope. | ||
| 11.3 | Internal/external vulnerability scanning including ASV | ✓ | Merchant maintains its required scan programme; DX3 supports/coordinates hosted-scope scans as agreed and remediates findings attributable to managed infrastructure. Client remediates application findings. | ||
| 11.4 | Penetration testing | ✓ | DX3 is responsible for tests required of infrastructure/services in its scope; client is responsible for application/merchant-scope testing. Coordination is required where scopes overlap. | ||
| 11.5 | Intrusion detection/prevention and change-detection mechanisms | ✓ | DX3 operates managed infrastructure monitoring/security controls; client is responsible for application-level controls not supplied by DX3. | ||
| 11.6 | Detect unauthorised changes to payment pages/security-impacting HTTP headers/scripts | ✓ | Client owns payment-page integration and script inventory. For hosted iFrame payment pages, DX3 supports agreed CSP/WAF/client-side controls at the hosting layer; implementation must be confirmed for each merchant environment. | ||
| 12.1 | Information-security policy and responsibilities | ✓ | DX3 maintains its policy framework; client maintains its own merchant policies and responsibilities. | ||
| 12.2 | Targeted risk analyses where required by PCI DSS | ✓ | Each party performs and records TRAs for flexible-frequency controls it owns. | ||
| 12.3 | Acceptable use and security management of technologies | ✓ | Each party governs technologies and users under its control. | ||
| 12.4 | Service-provider PCI DSS compliance programme management | ✓ | DX3 executive management assigns accountability, operates the PCI programme and performs the service-provider review activities applicable to DX3. | ||
| 12.5.1 | Document PCI DSS scope | ✓ | DX3 documents the service-provider scope; client documents its merchant scope. | ||
| 12.5.2 | Validate scope and identify data flows/system components | ✓ | Each party validates its own scope and coordinates where DX3-hosted merchant systems overlap. | ||
| 12.5.2.1 | Service-provider scope confirmation at least every six months and after significant change | ✓ | DX3 performs and records the service-provider scope confirmation. | ||
| 12.5.3 | Review impact of significant organisational changes on PCI DSS scope | ✓ | DX3 performs the service-provider organisational-change review and communicates results to executive management. | ||
| 12.6 | Security-awareness programme | ✓ | DX3 trains DX3 personnel; client trains merchant personnel. | ||
| 12.7 | Personnel screening where required | ✓ | Each party is responsible for personnel screening obligations applicable to its own staff. | ||
| 12.8.1 | Maintain list of PCI-relevant third-party service providers | ✓ | DX3 maintains its TPSP register; client maintains its own TPSP/payment-provider register. | ||
| 12.8.2 | Written agreements with TPSPs acknowledging security responsibilities | ✓ | DX3 contracts with its TPSPs; client contracts with its own TPSPs/payment providers. | ||
| 12.8.3 | Due diligence before engaging TPSPs | ✓ | Each party performs due diligence on TPSPs it engages. | ||
| 12.8.4 | Monitor TPSP PCI DSS compliance status at least annually | ✓ | Each party monitors the PCI status of its own relevant TPSPs. | ||
| 12.8.5 | Maintain information about PCI DSS responsibilities of TPSPs and customers | ✓ | DX3 maintains this matrix for DX3/customer allocation and its own TPSP matrices; client must understand responsibilities of its own TPSPs. | ||
| 12.9.1 | TPSP acknowledges responsibility for security of account data it stores/processes/transmits or can impact | ✓ | DX3 acknowledges its service-provider responsibility within the managed service and contractual scope. | ||
| 12.9.2 | TPSP supports customer requests for PCI DSS status and responsibility information | ✓ | DX3 provides compliance status and responsibility information, including this matrix, to customers on reasonable request. | ||
| 12.10.1 | Incident response plan | ✓ | DX3 maintains its incident plan for managed hosting/infrastructure events; client maintains its merchant incident plan. | ||
| 12.10.2 | Review/test incident response plan | ✓ | Each party tests its own plan; coordinated exercises may be appropriate for shared scenarios. | ||
| 12.10.3 | Designated incident-response personnel availability | ✓ | Each party maintains responders appropriate to its responsibilities. | ||
| 12.10.4 | Responder training | ✓ | Each party trains its own incident responders. | ||
| 12.10.5 | Monitor/respond to security-system alerts | ✓ | DX3 handles managed infrastructure alerts; client handles merchant/application alerts. | ||
| 12.10.6 | Update incident response based on lessons learned/industry developments | ✓ | Each party updates its own plan and controls; material shared lessons are communicated. | ||
| 12.10.7 | Respond to PAN found where not expected | ✓ | DX3 follows its accidental-CHD procedure for managed infrastructure; client must notify DX3 promptly and handle its own merchant obligations. |
Need a copy for your assessment? Ask us for the matrix and current AOC.
Evidence, not badges
We can provide our current Attestation of Compliance and responsibility information for the contracted hosting service. Tell us which service you use and who is requesting the evidence.
Request PCI evidence →Primary guidance: PCI SSC Document Library · January 2025 SAQ A update · Outsourcing and merchant responsibility