PCI DSS scope is not a fixed attribute of a payment gateway or a merchant account — it is a function of your payment architecture. Every system, network segment, and process that stores, processes, or transmits cardholder data is within PCI scope and must comply with the applicable DSS requirements. This means your scope is determined by how payment data flows through your infrastructure, not by which gateway you use. A company that routes card data through its ERP, application server, or database has a dramatically larger PCI scope than a company that keeps card data entirely outside its environment through gateway-level tokenization.
The architectural decision that most affects PCI scope is where tokenization occurs. In a direct-post or hosted payment page model, the cardholder's browser sends card data directly to the gateway — your servers never see the PAN. The gateway returns a token that your application stores for future transactions. This approach typically qualifies for SAQ-A, the simplest PCI self-assessment questionnaire, with approximately 22 requirements. In contrast, a server-side integration where your application receives the card number, processes it, and forwards it to the gateway puts your application server, network, database, and potentially your ERP in scope — requiring SAQ-D with over 300 requirements.
For B2B payment operations, the critical design decision is how payment capture integrates with ERP posting. If the payment platform passes raw card data through the ERP (even transiently) to create the posting record, the ERP is in PCI scope. If the platform tokenizes at the gateway level and passes only the token and posting metadata to the ERP, the ERP remains out of scope. This distinction has real cost implications: PCI compliance for an in-scope ERP environment typically costs $50,000 to $150,000 annually in assessment, remediation, and ongoing monitoring — compared to $5,000 to $15,000 for a properly scoped SAQ-A environment.
PCI DSS v4.0 — which became mandatory in March 2025 — introduces additional requirements around script management, authenticated vulnerability scanning, and targeted risk analysis. For organizations with large PCI scope, these requirements add compliance cost and complexity. For organizations that have minimized scope through proper architecture, the incremental burden is minimal. The v4.0 transition is an opportunity to re-evaluate your payment architecture and reduce scope before the new requirements take full effect.
IT teams evaluating payment platforms should ask three specific questions. First: does the platform support gateway-level tokenization so that card data never enters our environment? Second: does the platform's ERP integration operate on tokens and posting metadata, or does it require card data to pass through the ERP? Third: what SAQ type does the platform's architecture support, and can the vendor provide a responsibility matrix showing which PCI requirements are covered by the platform versus the merchant? The answers to these questions determine your PCI scope, your compliance cost, and your ongoing security posture.