The Complete Guide to PCI-DSS Compliant Payment Data Collection

Collecting payment data through web forms involves a compliance environment that most organizations underestimate when they first set up an online payment workflow. The Payment Card Industry Data Security Standard imposes specific technical and process requirements on any system that stores, processes, or transmits cardholder data, and the cost of getting it wrong includes fines, increased transaction fees, mandatory forensic investigations after incidents, and loss of the ability to accept card payments entirely.

For organizations building payment data collection workflows, here is a complete guide to what PCI-DSS actually requires and how to satisfy those requirements with web-based forms.

What PCI-DSS Covers and Who It Applies To

PCI-DSS is established by the PCI Security Standards Council, which is governed by the major card networks: Visa, Mastercard, American Express, Discover, and JCB. It applies to any organization that stores, processes, or transmits cardholder data, including merchants, service providers, payment processors, and any other entity in the payment data chain.

The standard is currently in version 4.0, which became required in March 2024. PCI-DSS 4.0 introduced new requirements around multi-factor authentication, expanded web-based payment security, and a customized approach option that allows organizations to meet requirement intent through alternative controls where appropriate.

Non-compliance does not create direct criminal liability, but it can result in significant financial consequences. Acquiring banks can impose fines, increase transaction fees, or terminate merchant agreements. After a breach, the organization is typically required to fund a forensic investigation by a Qualified Security Assessor and remediate findings before card processing can resume. The reputational consequences extend well beyond the direct financial costs.

Understanding the Cardholder Data Environment

PCI-DSS scope is defined by the cardholder data environment (CDE): the systems, people, and processes that store, process, or transmit cardholder data, plus any systems connected to or that could affect the security of the CDE.

This scope definition matters because the controls required by PCI-DSS apply to everything within the CDE. A web form that collects cardholder data is in scope. The web server hosting the form is in scope. The systems the web server connects to may also be in scope depending on their function. The broader the CDE, the more systems require PCI-DSS controls, and the higher the total compliance cost.

Most organizations approaching PCI-DSS compliance look for ways to limit the CDE. The most effective approach is using a PCI-certified third-party platform to handle cardholder data within its own assessed environment, so the data does not pass through the organization’s own systems. This is sometimes called CDE scope reduction or descoping, and it is one of the most consequential decisions in a PCI-DSS implementation strategy.

Self-Assessment Questionnaires

PCI-DSS uses a Self-Assessment Questionnaire (SAQ) framework that provides different questionnaires for different payment environments. The correct SAQ for an organization depends on how cardholder data is handled in that organization’s specific environment.

SAQ A applies to organizations that have fully outsourced cardholder data functions to PCI-compliant third-party service providers, with no electronic storage, processing, or transmission of cardholder data on the organization’s own systems. This is the most limited scope and is achievable for organizations using fully redirected or fully hosted payment pages.

SAQ A-EP applies to e-commerce merchants that have partially outsourced payment processing but where the merchant’s website could affect the security of the payment page. This typically applies to inline payment forms where the merchant’s site presents the payment form and the payment processor handles the actual transaction.

SAQ D applies to all merchants and service providers that do not qualify for a simpler SAQ. This is the most comprehensive questionnaire and applies to organizations that store cardholder data or have complex payment environments that do not fit the narrower SAQ categories.

Identifying the correct SAQ is critical. Using a simpler SAQ than the environment warrants understates compliance obligations and creates exposure that becomes visible when a Qualified Security Assessor evaluates the full environment.

How PCI-DSS Applies to Form-Based Payment Collection

Web forms that collect cardholder data are subject to PCI-DSS in ways that depend on how the form handles the card data. The architectural choice has significant implications for scope and complexity.

Direct collection through the form, where the cardholder data passes through the organization’s web infrastructure on its way to a payment processor, places the entire web infrastructure in CDE scope. This requires substantial controls including network segmentation, file integrity monitoring, vulnerability scanning, and detailed audit logging across all systems involved.

Tokenized collection through a PCI-certified payment processor, where the cardholder data is handled directly by the processor’s PCI-certified environment without passing through the organization’s systems, keeps the organization’s infrastructure outside the CDE. The form collects the payment intent and donor or customer information; the processor handles the actual card transaction and returns a tokenized confirmation.

FormAssembly’s payment processor integrations (with Stripe, PayPal, and others) implement the tokenized approach. Cardholder data does not pass through or reside in FormAssembly’s infrastructure during transactions. The form collects the payment intent; the processor handles the card data within its own PCI-certified environment. This significantly reduces the merchant’s CDE scope compared to direct collection approaches.

FormAssembly’s PCI-DSS Level 1 Certification

FormAssembly is PCI DSS Level 1 certified, which is the highest assessment level for service providers. Level 1 certification requires an annual on-site audit by a Qualified Security Assessor that produces a Report on Compliance (ROC) documenting compliance with all PCI-DSS requirements. This is not a self-assessment.

For organizations using FormAssembly as part of a payment data collection workflow, the platform’s Level 1 certification provides documented evidence of the platform’s compliance posture. The ROC is available to customers as part of FormAssembly’s compliance documentation, supporting customer compliance documentation and reducing the vendor due diligence burden in customer PCI assessments.

Practical Implementation Steps

Implementing PCI-DSS compliant payment data collection through web forms typically follows a sequence of steps that produces both a working payment workflow and the compliance documentation to support it.

First, document the cardholder data environment and the scope of PCI-DSS compliance. Identify every system that touches cardholder data, including the form platform, the payment processor, and any internal systems that receive transaction confirmations.

Second, select the appropriate SAQ for the environment. Confirm that the architectural choices (tokenized vs. direct collection, hosted payment page vs. inline form) are consistent with the SAQ requirements.

Third, implement the form using a PCI-certified platform with a PCI-certified payment processor integration. Configure the form to collect payment intent and customer data without storing or transmitting raw card numbers through the organization’s own infrastructure.

Fourth, document the implementation. The PCI-DSS documentation requirements include network diagrams, data flow diagrams, system inventories, and policies covering the controls required by the applicable SAQ. This documentation is what an assessor reviews and what the organization defends during examination.

Fifth, complete the appropriate SAQ on the schedule required by the organization’s acquiring bank, typically annually. Maintain the documentation between assessments so that the next assessment cycle does not require reconstructing the compliance posture from scratch.