Payment application security is the discipline of protecting software that accepts, processes, transmits or stores payment card data, from the code running in a checkout terminal to an online shop's payment page and a processor's back-end systems. It covers how the software is designed, written, tested, delivered and updated, and how it is configured once it runs in a merchant's or service provider's environment.
The topic sits within the wider card security framework set by the PCI Security Standards Council. PCI DSS governs the environments where card data is handled, while separate PCI standards address the software itself. Payment application security is closely linked to the cardholder data environment, which the applications run in, and to the rules on cardholder data storage, which decide what the software may keep.
Payment application security in plain terms
A cash register is only as safe as the drawer, the lock and the person who built them. If the builder leaves a spare key inside or makes the drawer easy to pry open, the shop's careful staff cannot fully protect the takings.
Payment software is the modern cash register. It handles card numbers rather than notes, and attackers try to read those numbers as they pass through or find copies the software has left behind. Payment application security means building the software so it does not keep what it does not need, scrambles what it must keep, checks who is using it, and can be updated quickly when a weakness is found.
Standards for payment software
From 2008 the Council ran the Payment Application Data Security Standard (PA-DSS), which validated off-the-shelf payment applications sold to merchants. It was replaced by the PCI Software Security Framework, introduced in 2019, and PA-DSS validations expired in October 2022. The framework has two parts:
- PCI Secure Software Standard. It assesses an individual payment software product against security objectives such as protecting sensitive data, authentication, secure defaults and resistance to attack.
- PCI Secure Software Lifecycle (Secure SLC) Standard. It assesses a vendor's development process, so a qualified vendor can show that its software is built, tested and patched securely across releases.
PCI DSS v4.0, published in 2022 and updated as v4.0.1 in 2024, also applies to software that entities build or customise for themselves. Requirement 6 covers secure development, code review, vulnerability management and protection of public web applications. Two newer requirements, which became mandatory at the end of March 2025, target scripts on payment pages: requirement 6.4.3 calls for an inventory and authorisation of each script, and requirement 11.6.1 calls for a mechanism that detects unauthorised changes to the page.
Main threats
- Memory scraping and malware. Malicious code on a point-of-sale system reads card data in the brief moment it is unencrypted in memory.
- Web skimming. Attackers inject script into an e-commerce payment page that copies card details as the customer types them.
- Insecure storage. Logs, debug files or databases keep the full primary account number or, worse, prohibited data such as the card security code.
- Weak access and configuration. Default passwords, unpatched components and exposed administrative interfaces give attackers a way in, often leading to a data breach.
Common controls
Well-designed payment software avoids handling card data at all where possible. Tokenization replaces stored card numbers with substitutes, and point-to-point encryption, under its own PCI standard, encrypts card data inside the terminal so that the merchant's systems never see it in clear text. Cryptographic keys are generated and kept in a hardware security module. Other controls include secure coding training, static and dynamic code testing, penetration tests, signed software updates, strong authentication for administrators and detailed audit logs.
Mobile acceptance on ordinary phones and tablets, sometimes called tap to pay or SoftPOS, has its own PCI standard, Mobile Payments on COTS (MPoC), because the device was not built as a payment terminal. Card schemes and EMVCo add separate certification for chip and contactless kernels.
Responsibility and compliance
Responsibility is shared. Vendors are answerable for the security of what they ship and for timely patches, while merchants and service providers must install, configure and update it correctly. Using validated software does not by itself make a merchant compliant with PCI DSS, and acquirers can require evidence of both. As of November 2026, the current standards and lists of validated software are published by the PCI Security Standards Council.