PA-DSS Certified Software from PRIAM - find us on the validated payment application page of PCI Security Standards Council Website

What is PA-DSS

The Payment Application Data Security Standard (PA-DSS) is based largely on Visa's Payment Application Best Practices (PABP) program, which was introduced in 2005. As of October 2010, PABP has been replaced with PA-DSS v2. Further details can be found below:

13 sections of PA-DSS
PRIAM appease - e-commerce and CMS software
  1. Do not retain full magnetic stripe, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data
  2. Protect stored cardholder data
  3. Provide secure authentication features
  4. Log payment application activity
  5. Develop secure payment applications
  6. Protect wireless transmissions
  7. Test payment applications to address vulnerabilities
  8. Facilitate secure network implementation
  9. Cardholder data must never be stored on a server connected to the Internet
  10. Facilitate secure remote access to payment application
  11. Encrypt sensitive traffic over public networks
  12. Encrypt all non-console administrative access
  13. Maintain instructional documentation and training programs for customers, resellers, and integrators

Scope of PA-DSS

The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data as part of authorisation or settlement, where these payment applications are sold, distributed, or licensed to third parties.

The following guide can be used to determine whether PA-DSS applies to a given payment application:

  1. PA-DSS does apply to payment applications that are typically sold and installed "off the shelf" without much customisation by software vendors.
  2. PA-DSS does apply to payment applications provided in modules, which typically includes a "baseline" module and other modules specific to customer types or functions, or customised per customer request. PA-DSS may only apply to the baseline module if that module is the only one performing payment functions (once confirmed by a PA-QSA). If other modules also perform payment functions, PA-DSS applies to those modules as well. Note that it is considered a "best practice" for software vendors to isolate payment functions into a single or small number of baseline modules, reserving other modules for non-payment functions. This best practice (though not a requirement) can limit the number of modules subject to PA-DSS.
  3. PA-DSS does NOT apply to a payment application developed for and sold to only one customer since this application will be covered as part of the customer's normal PCI DSS compliance review. Note that such an application (which may be referred to as a "bespoke" application) is sold to only one customer (usually a large merchant or service provider), and it is designed and developed according to customer-provided specifications.
  4. PA-DSS does NOT apply to payment applications developed by merchants and service providers if used only in-house (not sold to a third party), since this in-house developed payment application would be covered as part of the merchant's or service provider's normal PCI DSS compliance.

For example, for the last two bullets above, whether the in-house developed or "bespoke" payment application stores prohibited sensitive authentication data or allows complex passwords would be covered as part of the merchant's or service provider's normal PCI DSS compliance efforts and would not require a separate PA-DSS assessment.

The following list, while not all inclusive, illustrates applications that are NOT payment applications for purposes of PA-DSS (and therefore do not need to undergo PA-DSS reviews):

  1. Operating systems onto which a payment application is installed (for example, Windows, Unix)
  2. Database systems that store cardholder data (for example, Oracle)
  3. Back-office systems that store cardholder data (for example, for reporting or customer service purposes

Relationship between PCI DSS and PA-DSS

The requirements for the Payment Application Data Security Standard (PA-DSS) are derived from the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Security Assessment Procedures. This document, which can be found at, details what is required to be PCI DSS compliant (and therefore what a payment application must support to facilitate a customer's PCI DSS compliance). Traditional PCI Data Security Standard compliance may not apply directly to payment application vendors since most vendors do not store, process, or transmit cardholder data. However, since these payment applications are used by customers to store, process, and transmit cardholder data, and customers are required to be PCI Data Security Standard compliant, payment applications should facilitate, and not prevent, the customers' PCI Data Security Standard compliance. Just a few of the ways payment applications can prevent compliance follow:

  1. Storage of magnetic stripe data in the customer's network after authorisation
  2. Applications that require customers to disable other features required by the PCI Data Security Standard, like anti-virus software or firewalls, in order to get the payment application to work properly
  3. Vendor's use of unsecured methods to connect to the application to provide support to the customer.

Secure payment applications, when implemented in a PCI DSS certified environment, will minimise the potential for security breaches leading to compromises of full magnetic stripe data, card validation codes and values (CAV2, CID, CVC2, CVV2), PINs and PIN blocks, and the damaging fraud resulting from these breaches.

To find out what PRIAM can do for your business get in touch:

Use our online enquiry form

Telephone: 01788 558 000
Fax: 01788 558 001