A MERCHANTS GUIDE
TO THE PAYMENT APPLICATION
DATA SECURITY STANDARD
(PA-DSS)
The mandatory guide for storing, processing or
transmitting cardholder information
Overview and applicability
Any application that stores, processes, or transmits cardholder data falls within the scope
of the Payment Card Industry Data Security Standards (PCI DSS). If this application is sold
to 3rd parties it falls within the compliance program known as Payment Application Data
Security Standard or PA-DSS (formally known as Visa's Payment Application Best Practices
[PABP]).
The goal of PA-DSS is to help software vendors and others develop secure payment
applications that do not store prohibited data, such as full magnetic stripe, CVV2 or PIN
data, and ensure their payment applications support compliance with the PCI DSS.
It is important to note that PA-DSS validated payment applications alone do not guarantee
PCI DSS compliance and that the validated payment application must be implemented in a
PCI DSS compliant environment. If you are a merchant it is your responsibility to ensure
you use PA-DSS compliant payment software, but it is the software developers’
responsibility to ensure it is built to meet the standard.
In scope
Out of scope
Payment applications that are sold,
distributed or licensed to third parties are
subject to the requirements of PA-DSS.
In-house payment applications developed
by merchants or service providers that are
not sold to a third party are not subject to
the PA-DSS requirements, but must still be
secured in accordance with the PCI DSS.
What does PA-DSS Compliance involve?
PA-DSS ensures that the payment software is compliant with 14 specific requirements
(similar to PCI DSS). Some of the headings you may recognise from PCI DSS and each
requirement have sub sections. The headline requirements are:
1. Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2,
CVV2), or PIN block data
Ensure that Sensitive Authentication Data is not stored and securely deleted
2. Protect stored cardholder data
Render the card number unreadable where it is stored and key management
3. Provide secure authentication features
Must facilitate the use of unique IDs and passwords
4. Log payment application activity
Produce an audit log of user access
5. Develop secure payment applications
Payment applications must be designed in line with PCI DSS and Industry best
practices
6. Protect wireless transmissions
If wireless permitted must be implemented in line with PCI DSS and industry best
practices.
7. Test payment applications to address vulnerabilities
Software vendors must establish a process to identify newly discovered security
vulnerabilities and have timely development and deployment of security patches and
upgrades
8. Facilitate secure network implementation
The application must not interfere with use of devices, applications, or configurations
required for PCI DSS compliance. For example, payment application cannot interfere
with anti-virus protection
9. Cardholder data must never be stored on a server connected to the Internet
The payment application must be developed such that the database server and web
server are not required to be on the same server
10. Facilitate secure remote software updates
If payment application updates are delivered via remote access into customers’
systems, software vendors must tell customers to turn on remote-access technologies
only when needed for downloads from vendor, and to turn off immediately after
download completes.
11. Facilitate secure remote access to payment application
If vendors or customers can access customers’ payment applications remotely, the
remote access must be implemented securely.
12. Encrypt sensitive traffic over public networks
If the payment application sends, or facilitates sending, cardholder data over public
networks, the PA must support use of strong cryptography and security protocols
13. Encrypt all non-console administrative access
If payment application or server allows non-console administration, the vendor
recommends use of SSH, VPN, or SSL/TLS for encryption of non-console administrative
access.
14. Maintain instructional documentation/training programs for customers, resellers, and
integrators
The Vendor must develop, maintain, and disseminate a PADSS Implementation
Guide(s) for its customers
Is the PA-DSS mandatory?
Yes. If you are in scope of the PA-DSS, there is a mandatory requirement to achieve
compliance. If you use a payment application there are key deadline dates to note. Please
contact the Payment Security team at paymentsecurity@worldpay.co.uk and we can
discuss them with you.
Who mandates security review and approval of payment
applications?
The PCI Security Standards Council (PCI SSC) has established the guidelines and the Card
Schemes (Visa Europe and MasterCard) serve as the source of enforcement. Processors,
Acquirers and manufacturers are the mechanisms by which the regulations will be
implemented.
What protection does a PA-DSS application provide?
Applications that have successfully completed a PA-DSS audit are certified to not retain or
compromise what is considered to be secure elements of the card’s track data [full
magnetic stripe data, card validation codes and values (CAV2, CID, CVC2, and CVV2), PINs
and PIN blocks. A PA-DSS certified application can also facilitate merchants in meeting a
number of requirements included in PCI DSS. In particular;
R1: Don’t retain full magnetic stripe, card validation code/value (SAD), or PIN block data
R2: Do not use computer passwords that have been provided by external suppliers
R3: Protect stored cardholder data
R4: Encrypt transmission of cardholder data across open, public net-works
R6: Develop and maintain secure systems and applications
R7: Restrict access to cardholder data by business need-to-know
R10: Regularly check who accesses your computers and cardholder data that you hold
R12: Create/maintain own security policy to ensure you remain compliant with PCI DSS
For further clarification and guidance it is always advisable to make contact with a
Payment Application Qualified Security Assessor (PA-QSA). For a full list of approved
assessors
please
visit
the
official
Security
Standard
Councils
website
https://www.pcisecuritystandards.org
Benefits of using PA-DSS software include:
ƒ
ƒ
ƒ
ƒ
Prevents storage of sensitive cardholder data
Reduces opportunities for compromise and misuse
Ensures payment solutions meet the highest levels of security
Supports merchants PCI DSS compliance
Where can I find more information on PA-DSS?
You can contact your payment software supplier or you should engage with a PA-QSA for
more detailed information and specific requirements for your business. If you are already
using a QSA to confirm compliance, speak to them about PA-DSS too. The PCI Security
Standards Council (PCI SSC) is also a reliable place to read more detail on PA-DSS. Some
useful links include:
https://www.pcisecuritystandards.org/pdfs/pci_pa_dss_program_guide.pdf
https://www.pcisecuritystandards.org/security_standards/vpa/
https://www.pcisecuritystandards.org/security_standards/pci_pa_dss.shtml
Guide to whether PA-DSS applies to a given payment
application:
ƒ
PA-DSS does apply to payment applications that are typically sold and installed “off
the shelf” without much customisation by software vendors.
ƒ
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.
ƒ
PA-DSS does NOT apply to payment applications offered by application or service
providers only as a service (unless such applications are also sold, licensed, or
distributed to third parties) because:
1. The application is a service offered to customers (typically merchants) and the
customers do not have the ability to manage, install, or control the application or its
environment;
2. The application is covered by the application or service provider’s own PCI DSS review
(this coverage should be confirmed by the customer); and/or
3. The application is not sold, distributed, or licensed to third parties.
Examples of these
applications include:
“software
as
a
service”
payment
¾
Those offered by Application Service Providers (ASP) who host a payment application
on their site for their customers’ use. Note that PA-DSS would apply, however, if the
ASP’s payment application is also sold to, and implemented on, a third-party site, and
the application was not covered by the ASP’s PCI DSS review.
¾
Virtual terminal applications that reside on a service providers’ site and are used by
merchants to enter payment transactions. Note that PA-DSS would apply if the virtual
terminal application has a portion that is distributed to, and implemented on, the
merchant’s site, and was not covered by the virtual terminal provider’s PCI DSS
review.
ƒ
PA-DSS does NOT apply to non-payment applications that are part of a payment
application suite. Such applications (e.g. a fraud-monitoring, scoring, or detection
application included in a suite) can be, but are not required to be, covered by PA-DSS
if the whole suite is assessed together. However, if a payment application is part of a
suite that relies on PA-DSS requirements being met by controls in other applications in
the suite, a single PA-DSS assessment should be performed for the payment
application and all other applications in the suite upon which it relies. These
applications should not be assessed separately from other applications they rely upon
since all PA-DSS requirements are not met within a single application
ƒ
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”) is sold to only one customer (usually a large merchant or service provider),
and it is designed and developed according to customer-provided specifications.
ƒ
PA-DSS does NOT apply to payment applications developed by merchants and service
providers if used only in-house (not sold, distributed, or licensed 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.