Master PCI DSS Compliance

A master guide to PCI DSS (Payment Card Industry Data Security Standard) compliance for handling cardholder data. Covers the 12 core requirements across six control families (secure network, cardholder-data protection, vulnerability management, access control, monitoring, and security policy), the four merchant compliance levels by transaction volume (Level 1: over 6 million transactions/year requiring an annual ROC, down to Level 4: under 20,000 e-commerce transactions), and the three SAQ types by exposure (SAQ A for hosted-payment-page e-commerce at roughly 20 questions, SAQ A-EP for embedded JS payment forms at roughly 180 questions, SAQ D for full card-data handling at roughly 300 questions).

It draws a hard data-minimization line: CVV, full magnetic-stripe track data, and PIN or PIN blocks may never be stored under any circumstances, while PAN, cardholder name, expiration date, and service code may be stored only if encrypted.

### NEVER STORE THESE
PROHIBITED_DATA = {
    'full_track_data': 'Magnetic stripe data',
    'cvv': 'Card verification code/value',
    'pin': 'PIN or PIN block'
}

It gives concrete code for provider tokenization (Stripe token creation client-side, charging and storing via token server-side), a custom token-vault pattern (Fernet-encrypted card data behind a random token) for cases requiring self-managed storage, AES-256-GCM encryption at rest, TLS and secure-cookie configuration for data in transit, role-based access-control decorators with audit logging, and Luhn-algorithm card-number validation.

Use it when building payment-processing systems, handling credit-card information, implementing secure payment flows, conducting or preparing for a PCI DSS assessment, reducing PCI compliance scope, or implementing tokenization and encryption for cardholder data.

Input: a payment system or codebase needing PCI-compliant data handling, tokenization, encryption, or an SAQ-readiness review. Output: a PCI compliance checklist across six control areas (network security, data protection, vulnerability management, access control, monitoring, policy), tokenization and encryption code, access-control decorators with audit logging, and a list of eight common violations to check against - storing CVV, unencrypted PAN, weak encryption, missing access controls or audit logs, insecure transmission, default passwords, and no security testing.

Built around Stripe's tokenization API as the primary example, the cryptography package's Fernet and AESGCM for encryption, and Flask/flask_talisman for enforcing HTTPS and secure cookies. Ships companion reference files (references/tokenization.md, references/encryption.md, references/access-control.md, references/audit-logging.md) and a standalone scripts/audit-payment-system.sh compliance-audit script.

Developers and security engineers building or auditing systems that touch cardholder data who need concrete PCI DSS requirements, not just the standard's abstract text.