PCI DSS Compliance Guide
A practical guide to PCI DSS compliance for developers building payment integrations. Covers Self-Assessment Questionnaire (SAQ) types, tokenization strategies for scope reduction, card vault architectures, and a responsibility matrix for major payment processors.
What Is PCI DSS
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements established by the PCI Security Standards Council (founded by Visa, Mastercard, American Express, Discover, and JCB). Any organization that stores, processes, or transmits cardholder data must comply. The current version is PCI DSS v4.0.1, which became mandatory on March 31, 2025.
PCI DSS has 12 top-level requirements organized into 6 goals: build and maintain a secure network, protect cardholder data, maintain a vulnerability management program, implement strong access control, regularly monitor and test networks, and maintain an information security policy.
SAQ Types
The SAQ you complete depends on how your systems interact with cardholder data. Choosing the right integration architecture directly determines your SAQ level and compliance burden.
| SAQ Type | Description | Typical Use | Questions | Scope |
|---|---|---|---|---|
| SAQ A | All cardholder data functions fully outsourced to a PCI-compliant third party. No electronic storage, processing, or transmission of card data on your systems. | Hosted payment pages (Stripe Checkout, Adyen Drop-in with redirect), embedded iframes where card fields are served by the processor | 22 questions | Lowest -- your servers never touch card data |
| SAQ A-EP | E-commerce merchants that partially outsource payment processing but whose website controls the page that delivers the payment form to the cardholder. | Stripe Elements, Adyen Components, Braintree hosted fields -- card fields are in processor iframes, but your page loads them | 191 questions | Moderate -- your web server serves the page containing payment iframes |
| SAQ B | Merchants using imprint machines or standalone dial-out terminals only. No electronic card data storage. | Physical retail with standalone POS terminals (no internet connection to merchant systems) | 41 questions | Low -- applies to physical-only card acceptance |
| SAQ C | Merchants with payment application systems connected to the internet. No electronic card data storage. | Internet-connected POS terminals, virtual terminals processing one transaction at a time | 160 questions | Moderate -- internet-connected payment systems without stored card data |
| SAQ D (Merchant) | All other merchants not covered by SAQ A through C. Applies when merchants store, process, or transmit card data themselves. | Direct API integration handling raw card numbers, server-side card processing, any card data storage | 329 questions (full ROC equivalent) | Highest -- full PCI DSS assessment |
| SAQ D (Service Provider) | Service providers that store, process, or transmit cardholder data on behalf of other entities. | Payment gateways, processors, tokenization services, card vault providers | 347 questions | Highest -- full assessment plus service provider requirements |
Tokenization Strategies
Tokenization replaces sensitive card data with a non-sensitive token. The original card data is stored in a PCI-compliant vault, and the token is used in its place for storage and processing. Two primary approaches:
- Processor tokenization:The payment processor (Stripe, Adyen, Braintree) handles vaulting. You receive a token (e.g., Stripe's
pm_xxxPaymentMethod ID) that represents the card in their vault. This is the simplest path to SAQ A / SAQ A-EP and removes card data from your environment entirely. - Independent card vault: A dedicated PCI-compliant vault service (e.g., Basis Theory, VGS, TokenEx, Skyflow) stores card data and provides tokens. This approach offers processor portability -- you can route the same card to multiple processors without re-collecting card details. Trade-off: additional vendor, cost, and integration complexity.
PCI Scope Reduction
The most effective PCI strategy is reducing scope -- minimizing the systems, networks, and people that interact with cardholder data. Key techniques:
- Hosted payment pages: Redirect to the processor's checkout (Stripe Checkout, Adyen redirect). Card data never touches your domain.
- Iframe-based fields: Embed processor-hosted card input fields (Stripe Elements, Adyen Components, Braintree Hosted Fields) in your page. Card data goes directly from the iframe to the processor.
- Network segmentation: Isolate any systems that must handle card data on a separate network segment with strict access controls and monitoring.
- Point-to-point encryption (P2PE): For physical terminals, P2PE encrypts card data at the reader hardware, so it transits your network in encrypted form only.
- Avoid storage: Never store the full PAN, CVV, or magnetic stripe data. If you must display a card number, show only the last 4 digits.
Processor Responsibility Matrix
When using hosted fields or iframes from major processors, PCI responsibilities are shared. This table shows the division when using iframe-based integrations (SAQ A-EP level).
| Responsibility Area | Stripe | Adyen | Braintree | Merchant |
|---|---|---|---|---|
| Card data entry UI | Stripe (Checkout / Elements iframe) | Adyen (Drop-in / Components iframe) | Braintree (Hosted Fields iframe) | Merchant builds nothing for card entry |
| Encryption in transit | Stripe (TLS to Stripe servers) | Adyen (TLS to Adyen servers) | Braintree (TLS to Braintree servers) | Merchant ensures TLS on their domain |
| Card data storage | Stripe (PCI Level 1 vault) | Adyen (PCI Level 1 vault) | Braintree (PCI Level 1 vault) | Never stored on merchant servers |
| Tokenization | Stripe (PaymentMethod / Token objects) | Adyen (recurringDetailReference) | Braintree (payment method nonce / vault) | Merchant stores processor tokens only |
| 3DS / SCA | Stripe (Radar, automatic 3DS) | Adyen (3DS2 native, RevenueProtect) | Braintree (3DS via Cardinal) | Merchant implements client-side handling |
| PCI audit / SAQ | Stripe maintains PCI Level 1 | Adyen maintains PCI Level 1 | Braintree maintains PCI Level 1 | SAQ A (hosted) or SAQ A-EP (elements) |
Disclaimer: This guide provides a technical overview of PCI DSS and should not be treated as compliance or legal advice. PCI DSS requirements are complex and vary based on your specific implementation. Consult a Qualified Security Assessor (QSA) and the PCI Security Standards Council for authoritative guidance.