Map every component
Website, checkout, scripts, iframe or redirect, gateway, processor, devices, networks, accounts, plugins, integrations, logs, and support access.
Payment security responsibility
PCI Compliance for CMS Max eCommerce
Choose the payment architecture, then document the merchant, provider, platform, and validation responsibilities.
PCI DSS scope cannot be determined by a website plan or trust seal. It depends on how cardholder data and payment pages are handled across the complete merchant environment.
- PCI DSS v4.0.1
- Merchant responsibility
- Provider evidence
- Architecture-specific scope
Start with the payment flow
PCI scope follows the actual architecture, not the marketing label.
CMS Max supports configurable payment workflows, but the merchant must understand where payment-page elements originate, which systems store, process, or transmit account data, which people and devices can affect the environment, and who requires validation evidence.
Choose and verify providers
Confirm provider services, PCI status, shared responsibilities, integration method, evidence, incident terms, and change notifications.
Validate the right way
Confirm the applicable SAQ, Report on Compliance, scans, testing, attestations, deadlines, and submission path with the responsible entity.
Shared responsibility model
Assign every payment-security responsibility to a named owner.
The exact division varies by merchant and provider agreement. Use this model for discovery, then replace it with the documented architecture and current compliance evidence.
Business environment and validation
Payment methods, accounts, staff, access, policies, devices, networks, vendors, ecommerce content, changes, incidents, evidence, and required submissions.
Payment services and provider controls
Hosted or embedded payment elements, tokenization, authorization, settlement, fraud services, provider evidence, incidents, and contractual responsibilities.
Platform and scoped implementation
Configured checkout or form integration, website controls, credentials handling, changes, support access, testing, documentation, and platform responsibilities in the agreement.
Validation requirements and review
Merchant level, applicable SAQ or report, scans, evidence, attestations, deadlines, exceptions, compensating controls, and submission acceptance.
CMS Max payment architecture
Provider support does not make every checkout path equivalent.
The current application contains provider-specific integrations and settings. Features, methods, credentials, tokenization, refunds, test modes, fraud controls, checkout compatibility, and compliance impact must be confirmed for the selected path.
01Customer checkout or payment formWebsite content and payment-page elements
02Configured payment providerStripe, Authorize.Net, CardPointe, or Paya/ACH where supported
03Processor and banking pathAuthorization, settlement, disputes, and funding
04CMS Max order or submissionProvider references, status, operational actions, and reporting
Important: This diagram is an operating overview, not a PCI scope determination. The exact browser, server, provider, account-data, device, network, and support paths require review.
SAQ eligibility is conditional
A hosted field, iframe, or redirect is not enough by itself.
PCI SSC states that SAQ A eligibility depends on all payment-page elements originating from PCI DSS compliant service providers and every other eligibility criterion being met. Merchants should confirm the correct validation path before assessment.
Operate the control environment
Treat payment security as a lifecycle after launch.
- 01
Inventory
Document payment channels, providers, accounts, domains, pages, scripts, systems, devices, networks, users, vendors, and data flows.
- 02
Scope and validate
Confirm the standard, merchant level, SAQ or report, scans, testing, evidence, attestation, deadlines, and receiving entity.
- 03
Protect and monitor
Manage access, credentials, changes, vulnerabilities, scripts, logging, incidents, providers, backups, and staff responsibilities.
- 04
Review changes
Reassess scope after checkout, gateway, plugin, domain, script, device, vendor, staff, network, or integration changes.
PCI compliance FAQ
Questions merchants should resolve with evidence.
This page is educational and is not a compliance certification, legal advice, or a substitute for the merchant's acquirer, payment brand, processor, or qualified assessor.
Does PCI DSS apply to small online merchants?
Yes. PCI SSC states that PCI DSS is intended for entities involved in payment processing, including merchants regardless of size or transaction volume. Validation and reporting requirements are determined by payment brands and the acquiring relationship.
Does using CMS Max automatically make a merchant PCI compliant?
No. Compliance depends on the complete merchant environment, payment architecture, providers, website controls, people, policies, devices, integrations, access, evidence, and applicable validation requirements.
Which PCI DSS version should a merchant review?
PCI SSC currently publishes PCI DSS v4.0.1 materials and aligned Self-Assessment Questionnaires. Merchants should confirm the current standard, required validation method, deadlines, and instructions with their acquirer, payment brand, processor, or qualified assessor.
Which SAQ should an eCommerce merchant complete?
CMS Max cannot determine that from a plan name. SAQ eligibility depends on the precise payment-page architecture and every eligibility criterion. Confirm the required validation path with the entity receiving the submission or a qualified assessor.
Does an iframe or redirect reduce PCI scope?
It can affect scope, but only when the implementation satisfies all applicable criteria. PCI SSC explains that SAQ A eligibility requires all payment-page elements to originate from compliant service providers and all other eligibility requirements to be met.
Which payment providers can CMS Max support?
The current CMS Max payment architecture includes configurable support for Stripe, Authorize.Net, CardPointe, and Paya or ACH workflows. Availability, checkout support, credentials, methods, refunds, fraud controls, and compliance scope vary by provider and implementation.
What should a merchant review after launch?
Monitor payment-page changes, access, scripts, providers, domains, certificates, vulnerabilities, incidents, logs, devices, integrations, staff changes, evidence, annual validation, and provider attestations as applicable.
Start with the payment architecture
Bring CMS Max the providers, channels, and validation requirements.
CMS Max can help document the platform and implementation path while the merchant confirms the applicable compliance obligations and evidence.
Building Relationships with Web Developers and Marketing Agencies that want better results
The world's fastest and most SEO friendly website code.