PCI compliant software development builds applications that handle credit card data according to the Payment Card Industry Data Security Standard (PCI DSS). Any company that stores, processes, or transmits cardholder data must comply. The standard applies regardless of company size: a SaaS platform processing 10 transactions per month faces the same security requirements as one processing 10 million, though the validation method differs by volume.
Most companies avoid PCI scope entirely by using third-party payment processors (Stripe, Braintree, Adyen) that handle card data on the company's behalf. This works until the business needs to store card data for recurring billing with custom logic, build a payment platform that routes transactions across multiple processors, operate a marketplace where funds split between multiple parties, or integrate payment processing into an existing enterprise system where the third-party widget approach breaks the workflow. At that point, the company needs custom PCI compliant software.
What does PCI DSS actually require?
PCI DSS version 4.0 (effective March 2025, with full enforcement of new requirements by March 2025) organizes its requirements into six categories with twelve requirement groups. The standard is prescriptive: it tells you what to do, not just what outcome to achieve.
Build and maintain a secure network requires firewalls (or equivalent network security controls in cloud environments) between the cardholder data environment (CDE) and all other networks, and changing all vendor-supplied default passwords before deployment. Every system component in the CDE must be hardened: unnecessary services disabled, unused ports closed, administrative access restricted.
Protect cardholder data requires encrypting stored card data using strong cryptography with documented key management procedures, and encrypting cardholder data transmitted across open or public networks using TLS 1.2 or higher. The primary account number (PAN) must be rendered unreadable anywhere it is stored, whether through encryption, truncation, tokenization, or one-way hashing. Sensitive authentication data (CVV, PIN, full magnetic stripe) must never be stored after authorization, even if encrypted.
Maintain a vulnerability management program requires deploying anti-malware on all systems commonly affected by malicious software and developing secure software following industry standards. PCI DSS 4.0 added specific requirements for web application security: either a web application firewall (WAF) or regular automated vulnerability scanning of all public-facing web applications.
Implement strong access control requires restricting access to cardholder data on a business need-to-know basis, assigning unique IDs to every person with computer access, and restricting physical access to cardholder data environments. Multi-factor authentication (MFA) is required for all access to the CDE, not just remote access. PCI DSS 4.0 extended MFA requirements to all administrative access to the CDE, including from within the corporate network.
Regularly monitor and test networks requires logging all access to network resources and cardholder data, with logs retained for at least 12 months (3 months immediately available). Quarterly vulnerability scans by an Approved Scanning Vendor (ASV) and annual penetration testing are mandatory.
Maintain an information security policy requires a documented security policy that addresses all PCI DSS requirements, is reviewed annually, and is distributed to all relevant personnel. The policy must include an incident response plan that is tested at least annually.
What are the PCI compliance levels and which one applies?
PCI DSS defines four merchant levels based on annual transaction volume. The level determines how compliance is validated, not what requirements apply. All levels must meet the same security standards. The difference is whether a company self-assesses or undergoes a formal audit.
Level 1 applies to merchants processing over 6 million card transactions per year. Validation requires an annual on-site assessment by a Qualified Security Assessor (QSA) and quarterly network scans by an ASV. This is the most expensive validation path: QSA assessments typically cost $50,000-200,000 depending on the complexity of the cardholder data environment.
Level 2 applies to merchants processing 1-6 million transactions per year. Validation requires an annual Self-Assessment Questionnaire (SAQ) and quarterly ASV scans. Some acquirers may require a QSA assessment even at Level 2.
Level 3 applies to merchants processing 20,000-1 million eCommerce transactions per year. Level 4 applies to merchants processing fewer than 20,000 eCommerce transactions or up to 1 million non-eCommerce transactions per year. Both validate with an annual SAQ and quarterly ASV scans.
Service providers (companies that process, store, or transmit cardholder data on behalf of other businesses) have their own two-level system. Level 1 service providers (over 300,000 transactions per year) require a QSA assessment. Level 2 service providers self-assess. Payment facilitators, payment gateways, and hosted payment page providers are all classified as service providers regardless of their own transaction volume.
Where do standard payment integrations stop being sufficient?
Stripe Elements, Braintree Drop-in UI, and similar hosted payment fields keep the merchant out of PCI scope by ensuring card data never touches the merchant's servers. The card number goes directly from the customer's browser to the payment processor's infrastructure. This approach qualifies the merchant for SAQ A, the simplest self-assessment. It works for straightforward eCommerce checkouts and SaaS subscription billing.
Custom PCI compliant development becomes necessary in five situations.
Multi-processor payment routing is the first situation. A marketplace or platform that routes transactions to different processors based on geography, transaction type, or merchant category needs a payment orchestration layer. This layer touches transaction data and brings the system into PCI scope. The standard hosted payment field approach does not support routing logic because the merchant's server must make routing decisions based on transaction attributes.
Card-on-file with custom logic is the second situation. A B2B platform that stores tokenized card data and charges cards based on complex business rules (usage-based billing, tiered pricing, split payments across multiple invoices) needs custom token management. While the tokens themselves are not cardholder data, the system that manages them and initiates charges must follow PCI DSS requirements for secure development, access control, and logging.
Embedded payment systems are the third situation. A point-of-sale system, a kiosk application, or a mobile payment terminal that accepts card-present transactions processes cardholder data at the hardware level. The software controlling the payment terminal, managing encryption keys, and communicating with the processor is fully in PCI scope.
Payment platform development is the fourth situation. A company building a payment gateway, payment facilitator (PayFac), or payment processing platform for other merchants is a Level 1 service provider by definition. The entire platform is the cardholder data environment. Every line of code that handles transaction data must be developed under PCI DSS secure development requirements.
Enterprise system integration is the fifth situation. A company integrating payment processing into an existing ERP, order management, or billing system where the payment flow must be embedded in the enterprise workflow (not redirected to an external checkout page) brings the enterprise system's payment module into PCI scope. The CDE boundary must be defined within the larger enterprise application.
What does custom PCI compliant software development include?
A PCI compliant application has five security layers built into its architecture from the start. Retrofitting PCI compliance onto an application built without it is significantly more expensive than building it correctly from the beginning.
Network segmentation isolates the cardholder data environment from the rest of the application infrastructure. The CDE contains only the systems that store, process, or transmit cardholder data. Everything else (the web application, the admin dashboard, the reporting system) lives outside the CDE boundary. Segmentation reduces the scope of the PCI assessment: only systems inside the CDE boundary must meet the full PCI DSS requirements. In cloud environments, this means separate VPCs, security groups, and IAM policies for CDE and non-CDE resources.
Data protection implements encryption at rest and in transit for all cardholder data. PANs stored in the database are encrypted with AES-256 or equivalent, with encryption keys managed according to a documented key rotation schedule. Data in transit uses TLS 1.2 or higher for all connections. Tokenization replaces PANs with non-sensitive tokens for use outside the CDE: the application logic, reporting, and analytics systems work with tokens, never with actual card numbers.
Access control enforces role-based permissions with MFA for all CDE access. Every user action within the CDE is logged with a unique identifier. Service accounts that access cardholder data use individual credentials with least-privilege permissions. PCI DSS 4.0 requires that access reviews happen at least every six months, not just annually.
Logging and monitoring captures every event within the CDE: authentication attempts, data access, configuration changes, and system errors. Logs are tamper-evident (written to a system that CDE administrators cannot modify), retained for 12 months with 3 months immediately accessible, and reviewed daily (automated review with alerting is acceptable). A security information and event management (SIEM) system correlates events across CDE components and triggers alerts for suspicious patterns.
Secure development practices are built into the engineering process, not applied as an afterthought. Code reviews include security-focused review of all changes to CDE components. Automated static analysis scans code for common vulnerabilities (OWASP Top 10). Dependencies are monitored for known vulnerabilities and patched within defined timeframes. Development, staging, and production environments are separated, with no cardholder data in non-production environments.
How much does PCI compliant software development cost?
A custom payment integration with PCI compliance (tokenized card storage, single-processor billing, basic reporting) costs $60,000-120,000. A payment orchestration platform (multi-processor routing, marketplace fund splitting, merchant onboarding, compliance dashboard) costs $150,000-350,000. A full payment platform (PayFac or payment gateway from scratch) costs $400,000-800,000 and typically takes 9-18 months.
The compliance overhead (the additional cost beyond what the software would cost without PCI requirements) typically adds 30-50% to the development budget. This covers network segmentation architecture, encryption implementation and key management, logging infrastructure, access control systems, security testing, and documentation. Teams that try to add PCI compliance after the application is built typically spend 2-3x more than teams that build it in from the start, because retrofitting requires re-architecting the data flow, not just adding security features.
Ongoing compliance costs include quarterly ASV scans ($1,000-5,000 per quarter), annual penetration testing ($15,000-50,000), QSA assessment for Level 1 ($50,000-200,000 annually), WAF service ($200-2,000/month), SIEM service ($500-3,000/month), and staff training. For a Level 2 merchant self-assessing with SAQ D, annual compliance maintenance runs $30,000-60,000. For a Level 1 service provider, annual compliance costs are $150,000-400,000.
When should a company build custom PCI compliant software vs use a payment platform?
Use Stripe, Braintree, or a similar payment platform when: the payment flow is standard (checkout, subscription billing, one-time charges); a single processor handles all transactions; the hosted payment UI meets the product's design requirements; and the company wants to stay out of PCI scope entirely. This covers the majority of eCommerce and SaaS businesses.
Build custom when: the business model requires payment routing across multiple processors or acquirers; the platform is a marketplace or PayFac that splits funds between parties; payment processing must integrate into an enterprise system where the hosted widget approach breaks the workflow; the business is building a payment product (a gateway, a processor, a billing platform) as its core offering; or regulatory requirements in the business's industry mandate specific data handling that payment platform APIs do not support.
The decision comes down to whether payment processing is a commodity input to the business or a competitive differentiator. If payments are just plumbing (the company sells products, and cards are one way customers pay), use a platform. If the payment flow is the product or a core part of the product's value proposition (a marketplace's fund-splitting logic, a billing platform's usage-based pricing engine, a fintech's multi-currency routing), custom development is the path that produces a defensible product. The PCI compliance cost is the price of operating in the payments space, and companies that treat it as optional eventually discover it is not.
Need a team to build this for your business?