PCI DSS Certification: A Practical Guide for Payment System Developers

If you're building a system that touches cardholder data — processing payments, storing card numbers, or transmitting transaction information — PCI DSS compliance isn't optional. It's a requirement imposed by card networks (Visa, Mastercard, etc.) on every entity in the payment chain.

This article covers what PCI DSS actually requires, how certification levels work, and what we learned building PayWay — a payment processing system designed with PCI DSS architecture requirements in mind.

What Is PCI DSS?

Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements developed by the PCI Security Standards Council (founded by Visa, Mastercard, American Express, Discover, and JCB). Version 4.0, released in March 2022, is the current standard — with full enforcement since March 2025.

PCI DSS applies to any organization that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). This includes:

• Merchants — any business accepting card payments
• Service providers — payment processors, gateways, hosting providers
• Acquirers — banks that process card transactions for merchants
• Issuers — banks that issue payment cards

Certification Levels

PCI DSS defines four compliance levels based on annual transaction volume:

QSA = Qualified Security Assessor (external auditor certified by PCI SSC). ASV = Approved Scanning Vendor (performs external vulnerability scans). SAQ = Self-Assessment Questionnaire.

What Level 1 Actually Means

Level 1 is the strictest tier. It requires:

1. Annual Report on Compliance (ROC) — produced by a QSA after an on-site audit
2. Quarterly external vulnerability scans — by an ASV
3. Quarterly internal vulnerability scans
4. Annual penetration testing — both internal and external
5. Attestation of Compliance (AOC) — a formal statement signed by both the entity and the QSA

The on-site audit covers all 12 requirement families of PCI DSS (see below). It's thorough and typically takes several weeks of preparation + the audit itself.

The 12 PCI DSS Requirement Families

PCI DSS v4.0 organizes requirements into 6 goals and 12 families:

Build and Maintain a Secure Network and Systems

1. Install and maintain network security controls — firewalls, segmentation, access rules
2. Apply secure configurations — change vendor defaults, remove unnecessary services

Protect Account Data

1. Protect stored account data — encryption at rest, masking, retention policies
2. Protect data in transit — TLS 1.2+, no cleartext transmission over public networks

Maintain a Vulnerability Management Program

1. Protect against malware — anti-malware solutions on all systems
2. Develop and maintain secure systems and software — patch management, secure SDLC

Implement Strong Access Control Measures

1. Restrict access by business need-to-know — least privilege
2. Identify users and authenticate access — unique IDs, MFA for all access to CDE
3. Restrict physical access — to cardholder data environment (CDE)

Regularly Monitor and Test Networks

1. Log and monitor access — audit trails, time synchronization, log reviews
2. Test security regularly — vulnerability scans, penetration tests, IDS/IPS

Maintain an Information Security Policy

1. Support security with organizational policies — security awareness, incident response

What We Learned Building PayWay

PayWay is a payment processing system we're building for the African market (Uganda, ~10,000 devices). It handles both card-present and card-not-present transactions via a microservice architecture on Java 21 / Spring Boot 3.5. Here's what PCI DSS compliance looks like in practice for a project like this.

Architecture: Microservices with Clear Boundaries

PayWay is split into dedicated microservices — payway-card-present, payway-card-not-present, and payway-merchant (merchant portal). This separation isn't just for scalability — it's a PCI DSS best practice. Each service has a well-defined scope, making it easier to isolate the Cardholder Data Environment (CDE) and reduce audit surface.

The CDE is the scope of your PCI DSS audit. Everything that touches card data is in scope — and everything connected to it may be too. Microservice boundaries make segmentation natural.

Delegate Card Processing to Certified Providers

We integrated CyberSource (Visa's payment gateway) for transaction processing, and AWS Payment Cryptography for HSM-backed cryptographic key operations. Both are PCI DSS certified services.

Using certified providers for the most sensitive operations — card data handling, key management, fraud screening — is the single most effective way to reduce your own compliance scope. The actual card data flows through CyberSource infrastructure, not ours.

Key integrations in PayWay:

• CyberSource (CYBS) — card-present and card-not-present transaction processing
• AWS Payment Cryptography — hardware security module (HSM) operations for encryption keys
• PostgreSQL — transaction records, merchant data (no raw card numbers)

PCI DSS Best Practices Worth Highlighting

Based on our experience and the PCI DSS v4.0 requirements, here are practices every payment system team should consider:

1. Minimize data retention — never store CVV, full track data, or PIN blocks after authorization. Use tokenization to replace card numbers with non-reversible tokens immediately
2. Segment the CDE — isolate payment-handling services into a dedicated network segment with strict firewall rules. Services outside the CDE should communicate through APIs only
3. Automate evidence collection — QSA auditors want logs, configurations, scan results. Automate log aggregation (Requirement 10), vulnerability scanning (Requirement 11), and infrastructure-as-code for auditable configurations
4. MFA for all CDE access — PCI DSS v4.0 expanded this requirement. All administrative, remote, and console access to the CDE must use multi-factor authentication
5. Formal incident response plan — Requirement 12.10 mandates documented procedures for detection, containment, notification, and post-incident review
6. Don't treat compliance as a checkbox — PCI DSS is an ongoing process with quarterly scans and annual assessments, not a one-time certification

Common Mistakes to Avoid

1. Treating PCI DSS as a checkbox exercise — it's an ongoing process, not a one-time certification
2. Expanding CDE scope unnecessarily — flat networks where everything touches the payment path
3. Storing SAD after authorization — CVV, full magnetic stripe data, PIN blocks must never be stored post-auth
4. Ignoring PCI DSS v4.0 future-dated requirements — several requirements became mandatory in March 2025
5. Underestimating the audit timeline — Level 1 preparation takes 3–6 months for first-time certifications

PCI DSS v4.0: What Changed

Key changes from v3.2.1 to v4.0:

• Customized approach — organizations can now meet requirements through alternative controls (with QSA validation)
• Expanded MFA — required for all access into CDE, not just remote
• Targeted risk analysis — required for each requirement where "periodically" is mentioned
• Enhanced authentication — password length increased to 12+ characters
• Client-side security — new requirements for JavaScript and payment page integrity (Requirement 6.4.3)
• Automated log review — manual log reviews are no longer sufficient (Requirement 10.4.1.1)

When Do You Need PCI DSS?

You need it if:

• Your application processes, stores, or transmits card numbers (PAN)
• You provide services to entities that handle card data
• Your infrastructure hosts payment processing components

You may not need it if:

• You use a fully hosted payment page (like Stripe Checkout) where card data never touches your servers
• You only use tokenized data (tokens aren't subject to PCI DSS)

Even if you use a hosted payment page, you still have some PCI DSS requirements (SAQ A) — but the scope is dramatically reduced.

How We Can Help

At ONSOFT, we have hands-on experience building payment systems with PCI DSS architecture requirements. Our team currently develops PayWay — a card processing platform for the African market with CyberSource and AWS Payment Cryptography integration.

We can help with:

• Payment system architecture — microservice design with CDE segmentation, data flow analysis
• Payment gateway integration — CyberSource, AWS Payment Cryptography
• PCI DSS-aware development — secure coding practices, access controls, logging, encryption
• Infrastructure — Docker, Kubernetes, PostgreSQL for payment workloads