PCI DSS compliance for custom software means building payment processing systems where cardholder data is encrypted at rest and in transit, where the application never stores full card numbers or CVVs after authorization, where every access to payment data is logged with immutable audit trails, and where the code itself passes vulnerability assessments that PCI assessors run against the OWASP Top 10 and PCI-specific coding requirements. Off-the-shelf payment platforms (Stripe, Braintree, Adyen) handle PCI compliance within their own systems, but the moment a business needs custom payment flows, split payments, marketplace disbursements, subscription logic that the platform cannot support, or integration with legacy billing systems, the custom code that touches or routes payment data falls under PCI scope. That custom code must be built PCI-compliant from the architecture level, not patched into compliance after the fact.
PCI DSS 4.0, which became mandatory in March 2025, introduced significant new requirements for custom software: client-side script management (Requirement 6.4.3) that monitors every script running on payment pages, authenticated vulnerability scanning, and stricter requirements for multi-factor authentication on all access to cardholder data environments. Organizations running custom payment software built before PCI 4.0 likely need architectural changes, not just configuration updates.
What does PCI compliance actually require for custom software?
PCI DSS has 12 requirements organized into 6 categories. For custom software development, the requirements that directly affect how code is written and how systems are architected are Requirements 3, 4, 6, 7, 8, and 10. Requirement 3 governs how cardholder data is stored: the application must not store sensitive authentication data (CVV, full track data, PIN blocks) after authorization under any circumstances, primary account numbers (PANs) must be rendered unreadable anywhere they are stored (tokenization, truncation, one-way hashing, or strong encryption), and encryption keys must be managed with documented procedures including rotation schedules.
Requirement 4 covers data in transit: all cardholder data transmitted across open networks must use strong cryptography (TLS 1.2 or higher), and the application must not transmit PANs via unencrypted channels (email, SMS, chat). Requirement 6 is the development-specific requirement: secure coding practices, code review processes, vulnerability management, and protection against common application vulnerabilities. Requirement 7 restricts data access to need-to-know: the application's role-based access control must limit who can view, modify, or export cardholder data. Requirement 8 covers authentication: multi-factor authentication for all access to the cardholder data environment. Requirement 10 covers logging: every access to cardholder data, every administrative action, and every authentication attempt must be logged with immutable, tamper-evident audit trails retained for at least 12 months.
How does tokenization reduce PCI scope for custom applications?
Tokenization replaces cardholder data with a non-reversible token that has no value if intercepted. When the application needs to process a payment, it sends the token to the payment processor, which maps it back to the actual card data in their PCI-compliant vault. The custom application never sees, stores, or transmits the actual card number. This dramatically reduces the application's PCI scope because the systems that handle tokens are not processing cardholder data.
The architecture decision is where tokenization happens. In the most scope-reducing approach (SAQ A eligible), cardholder data is captured directly by the payment processor's hosted fields or iframe embedded in the application's payment page. The card number is typed into a field hosted by Stripe, Braintree, or Adyen, tokenized on their servers, and only the token reaches the custom application's backend. The application's servers never touch cardholder data at all.
When business requirements prevent the hosted-field approach (custom payment UIs, multi-processor routing, payment orchestration across providers), the application captures card data client-side, tokenizes it before it reaches the server, and routes the token to the appropriate processor. This increases PCI scope because the client-side code handles cardholder data briefly, triggering SAQ A-EP requirements. The architecture must ensure that the client-side tokenization is tamper-proof: Content Security Policy headers that prevent script injection, Subresource Integrity (SRI) checks on every script loaded on the payment page, and the PCI 4.0 requirement for continuous monitoring of all scripts executing on payment pages.
What changed with PCI DSS 4.0 for custom software?
PCI DSS 4.0 introduced several requirements that directly affect custom software development. Requirement 6.4.3 mandates that all payment page scripts are managed with documented authorization, integrity verification, and an inventory of every script with a business justification for why it runs on the payment page. This means the application must track every JavaScript file, inline script, and third-party script that loads on any page where cardholder data is entered. If a new script appears (from a compromised CDN, a malicious browser extension intercepting the page, or an unauthorized deployment), the system must detect and block it.
Requirement 6.3.2 requires a software inventory of all custom and third-party components, including libraries and frameworks, with a process for identifying vulnerabilities in those components. This is not just a one-time audit. The application must have a continuous process for monitoring its dependency tree against known vulnerability databases (CVE, NVD) and patching or mitigating vulnerabilities within defined timeframes: critical vulnerabilities patched within 30 days, high within 60.
Requirement 8.3.6 requires multi-factor authentication for all access to the cardholder data environment, not just remote access. This affects the application's admin panels, database access tools, deployment pipelines, and any interface that can reach cardholder data. MFA must use at least two of three factors (something you know, something you have, something you are) and cannot rely on SMS one-time passwords alone (PCI 4.0 considers SMS a weaker factor due to SIM-swap attacks).
How should PCI-compliant applications handle logging and audit trails?
PCI Requirement 10 specifies what must be logged: all individual user access to cardholder data, all actions taken by any individual with root or administrative privileges, access to all audit trails, invalid logical access attempts, use of identification and authentication mechanisms, initialization of audit logs, creation and deletion of system-level objects. Each log entry must include user identification, type of event, date and time, success or failure indication, origination of event, and identity or name of affected data, system component, or resource.
The critical architectural requirement is tamper evidence. Audit logs must be protected against modification. If an attacker (or a malicious insider) gains access to the system and modifies cardholder data, the logs recording that access must be unalterable. This means write-once storage, cryptographic chaining (each log entry's hash includes the previous entry's hash, creating a tamper-evident chain), or forwarding to a centralized log management system that the application servers cannot modify.
PCI 4.0 adds Requirement 10.4.1.1: automated mechanisms to perform audit log reviews. Manual log review is no longer sufficient. The application must include or integrate with automated log analysis that detects anomalies: unusual access patterns, bulk data exports, access from unexpected IP addresses or at unexpected times, and failed authentication attempts that may indicate a brute-force attack. The system must generate alerts for these anomalies and route them to security personnel within a defined timeframe.
What are the most common PCI compliance failures in custom software?
The most common failure is scope creep: cardholder data appearing in systems that were not designed to handle it. An application that routes card numbers through a logging system (the card number appears in debug logs), stores card data in session state or browser local storage, passes card numbers in URL parameters (which get logged by web servers and proxies), or includes card data in error messages has expanded PCI scope to every system those logs, sessions, or URLs touch. Fixing this after the system is built means tracing every code path where cardholder data flows and verifying that none of them leak data to out-of-scope systems.
The second most common failure is inadequate key management. PCI requires that encryption keys used to protect cardholder data are stored separately from the encrypted data, that keys are rotated on a documented schedule, that key access is restricted to the minimum number of custodians necessary, and that retired keys are securely destroyed. Applications that store encryption keys in application configuration files, environment variables accessible to the application runtime, or the same database as the encrypted data fail this requirement.
The third common failure is insufficient access controls. PCI requires that access to cardholder data is restricted on a need-to-know basis and that every access attempt is authenticated and logged. Applications where all authenticated users can view full card numbers, where support staff can export cardholder data without additional authorization, or where API keys grant broad access to payment data without individual user attribution fail Requirements 7 and 8.
When does a business need custom PCI-compliant software vs using a payment platform?
Payment platforms (Stripe, Braintree, Square, Adyen) handle the majority of PCI compliance for standard payment flows. For a business that collects payments through a standard checkout flow, these platforms keep PCI scope minimal. The business fills out SAQ A (the simplest self-assessment questionnaire) and is compliant.
Custom PCI-compliant software is necessary when: the business operates a marketplace that splits payments between multiple parties and needs custom disbursement logic the platform does not support, the billing model involves complex recurring charges with variable amounts, mid-cycle adjustments, and usage-based components that exceed the platform's subscription tools, the business must integrate payment processing with legacy systems (mainframe billing, custom ERP, proprietary financial systems) that the payment platform cannot connect to natively, the payment flow requires multi-processor routing (primary and fallback processors, geographic routing, cost optimization across processors), or regulatory requirements specific to the industry demand controls and audit trails beyond what the platform provides.
How does Madgeek build PCI-compliant custom software?
Madgeek builds PCI-compliant payment systems for eCommerce platforms, financial services applications, and marketplace businesses where standard payment platform capabilities are insufficient. The architecture approach mirrors the enterprise platform built for Tejas Networks: complete audit trails on every data access, role-based access controls, encrypted data handling, and compliance-grade logging. Payment-specific systems add tokenization architecture (minimizing PCI scope from the design phase), secure key management infrastructure, client-side script monitoring for PCI 4.0 compliance, and integration with payment processors through their server-side APIs.
PCI-compliant custom software projects typically run $60,000-$150,000 depending on the complexity of the payment flow and the number of integrations. The critical factor is getting the architecture right before code is written: the data flow diagram that maps where cardholder data enters, how it is tokenized or encrypted, where tokens flow through the application, and which systems are in versus out of PCI scope. Getting this wrong means rebuilding, not patching. Most engagements include preparation for the PCI assessment: documentation of the cardholder data flow, evidence of secure coding practices, vulnerability scan results, and penetration testing of the payment-handling components.
Need a team to build this for your business?