PCI DSS (the Payment Card Industry Data Security Standard) is a set of security requirements that applies to any system that stores, processes, or transmits cardholder data. For developers, the single most important principle is scope reduction: the less your application touches raw card numbers, the fewer controls you must implement and prove. If you use a compliant payment processor and never let the primary account number (PAN) hit your servers, you can shrink your compliance burden dramatically instead of securing your entire stack to card-industry standards.
What is PCI DSS, and does it apply to your application?
PCI DSS is maintained by the PCI Security Standards Council, a body founded by the major card brands (Visa, Mastercard, American Express, Discover, and JCB). It is a contractual requirement, not a government law, but the card brands and acquiring banks enforce it through your merchant agreement. Non-compliance can lead to fines, higher transaction fees, or losing the ability to accept cards entirely.
The standard applies whenever cardholder data enters your environment. Cardholder data includes the PAN, cardholder name, expiration date, and service code. A stricter subset, sensitive authentication data (the full magnetic stripe, CVV/CVC, and PIN), must never be stored after authorization, even encrypted. If your code ever handles these values, PCI DSS applies to that code and the systems around it.
How do you reduce PCI DSS scope?
Scope is the set of people, processes, and technology that touch cardholder data. Reducing it is the highest-leverage decision you will make, and it is largely an architectural choice:
- Use hosted payment fields or a redirect. With an iframe-based field (Stripe Elements, Braintree Hosted Fields, Adyen Components), the card number is captured directly by the processor's domain and never traverses your backend.
- Tokenize early. Exchange the PAN for a non-sensitive token you can safely store and reuse for refunds or recurring billing. Your database then holds tokens, not card data.
- Segment your network. Keep any systems that do touch cardholder data isolated from the rest of your infrastructure so an assessor only evaluates that small segment.
- Avoid logging. Ensure card numbers never leak into application logs, crash reports, analytics events, or support tickets.
A merchant that fully outsources card handling to a compliant provider may qualify for the shortest self-assessment questionnaire (SAQ A). A merchant whose servers receive raw PANs falls under the far more demanding SAQ D, which mirrors nearly all of the standard's requirements. Choosing the right integration pattern early is the difference between weeks and months of compliance work.
Which PCI DSS requirements matter most to developers?
The current standard, PCI DSS v4.0, organizes 12 requirements into six control objectives. Several map directly to engineering work:
- Requirement 3 - Protect stored account data. If you must store the PAN, render it unreadable using strong cryptography, and never store sensitive authentication data post-authorization.
- Requirement 4 - Encrypt data in transit. Use TLS with current cipher suites for any transmission of cardholder data across open networks.
- Requirement 6 - Develop and maintain secure systems and software. Follow secure coding practices, patch known vulnerabilities promptly, and manage change control.
- Requirement 8 - Authenticate access. Enforce unique IDs, strong authentication, and multi-factor authentication for access into the cardholder data environment.
- Requirement 11 - Test security regularly. Run vulnerability scans and penetration tests, and monitor for change on payment pages (a v4.0 addition aimed at e-commerce skimming).
Secure coding practices for cardholder data
Requirement 6 expects you to defend against the vulnerability classes catalogued by the OWASP Foundation. In practice, that translates into a concrete set of habits for any team building payment features:
- Validate and sanitize all input, and use parameterized queries to prevent injection.
- Never hard-code cryptographic keys, database credentials, or API secrets; manage them in a dedicated secrets store and rotate them.
- Encrypt cardholder data at rest with keys that are stored and rotated separately from the data they protect.
- Mask the PAN in every user-facing surface, showing at most the first six and last four digits.
- Add integrity checks and a strict Content Security Policy to payment pages so a compromised third-party script cannot exfiltrate keystrokes.
- Review code and run dependency and static analysis in CI so vulnerable libraries are caught before release.
Common PCI DSS mistakes developers make
Most assessment failures are not exotic; they are recurring oversights:
- Accidentally logging card data through verbose request logging or third-party error trackers.
- Storing the CVV "to make retries easier" - this is explicitly forbidden and is a serious violation.
- Treating tokens as the finish line while still routing the raw PAN through the backend before tokenizing.
- Ignoring test data such as real card numbers pasted into staging environments or fixtures.
- Assuming the processor covers everything - a hosted field reduces scope but does not remove your responsibility for the page that embeds it.
A developer's PCI DSS checklist
- Map the data flow: identify every point where card data could enter your system.
- Choose an integration (hosted fields, redirect, or tokenization) that keeps the PAN off your servers.
- Confirm which SAQ type applies once the architecture is set.
- Enforce TLS everywhere and strong, MFA-backed authentication for privileged access.
- Remove card data from logs, analytics, backups, and test fixtures.
- Build secure coding, dependency scanning, and code review into your pipeline.
- Schedule vulnerability scans and penetration tests, and document evidence for your assessor.
Teams building payment features into fintech solutions benefit from treating compliance as an architectural constraint from day one, rather than retrofitting controls onto a finished product. The same discipline applies to any custom development effort that touches regulated data.
Frequently asked questions
Do I need PCI DSS compliance if I use Stripe or another processor?
Yes, but at a much lower level of effort. Using a compliant processor with hosted fields moves most obligations to the provider, yet you remain a merchant and must still complete the appropriate self-assessment questionnaire and secure the systems you control, including your payment page.
What is the difference between tokenization and encryption?
Encryption transforms the PAN into ciphertext that can be reversed with a key, so the sensitive value still exists in your environment. Tokenization replaces the PAN with a surrogate value that has no mathematical relationship to the original, so the real card number lives only in the token vault - which is why tokenization is so effective at reducing scope.
Can I store card numbers if I encrypt them?
You may store the PAN if you render it unreadable and meet the full set of storage, key-management, and access controls. You may never store sensitive authentication data such as the CVV after authorization, regardless of encryption. In most cases, tokenizing instead of storing is the better engineering decision.
Which PCI DSS version is current?
PCI DSS v4.0 (with the v4.0.1 revision) is the active standard; its future-dated requirements became mandatory in 2025. Always design against the current version rather than earlier releases, as several v4.0 controls target modern threats like e-commerce skimming.
How Direlli can help
Direlli builds secure, compliance-ready payment and financial software for clients across the US, Europe, and MENA, and holds a 5.0 rating on Clutch. Our engineers design payment flows that minimize PCI DSS scope from the start, implement tokenization and secure coding practices, and prepare your codebase for assessment. To discuss your project, get in touch.
