New credit card security standards regarding PA-DSS Compliance

Question

The new credit card standards including PA-DSS can be quite confusing for software companies.

My question is this: If your software company designs a POS software system (like we do) which utilizes a locally installed 3rd party credit card processor (which is PA-DSS compliant) to encrypt, transmit and process the credit cards, does our POS system have to pass PA-DSS certification then?

The end users enters the data into our custom designed UI / Payment screen in our application. We do not ever store this information at any point in time in a database, text file etc of any kind. The information is taken from the user interface and loaded into variables in RAM and then passed to the 3rd party software system via their locally installed API. The 3rd party processor then encrypts, submits and processes the credit card information and they are PA-DSS compliant.

So, do we need to be since we are not storing, transmitting or processing the credit card data. We are transmitting the credit card information only from RAM to an API call.

Answer 1

So, do we need to be since we are not storing, transmitting or processing the credit card data. We are transmitting the credit card information only from RAM to an API call.

Your second statement is contradicting the first, and more importantly, holds the answer to your question.

PCI DSS v2 states the following,

PCI DSS applies wherever account data is stored, processed or transmitted. Account Data consists of Cardholder Data plus Sensitive Authentication Data, as follows:

• Cardholder Data includes:
  • Primary Account Number (PAN)
  • Cardholder Name
  • Expiration Date
  • Service Code
• Sensitive Authentication Data includes:
  • Full magnetic stripe data or equivalent on a chip
  • CAV2/CVC2/CVV2/CID
  • PINs/PIN blocks

and I would presume that transmission of the credit card number (which constitutes handling of card holder data) to the third party application would render your POS software to be compliant as well. The question is whether your software should be PCI DSS or PA-DSS compliant, and that is addressed in the section on the "Relationship between PCI DSS and PA DSS":

note the following regarding PA-DSS applicability:

• PA-DSS does apply to payment applications that are typically sold and installed “off the shelf” without much customization by software vendors.
• 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.

Answer 2

You say your application takes credit card data in to pass on to another application?

This means you are handling it - I would class what you are doing as transmitting CC data according to PA guidance (relevant parts in bold):

The scope of the PA-DSS review should include the following:

• Coverage of all payment application functionality, including but not limited to

  1) end-to-end payment functions (authorization and settlement)

  2) input and output

  3) error conditions

  4) interfaces and connections to other files, systems, and/or payment applications or application components

  5) all cardholder data flows

  6) encryption mechanisms

  7) authentication mechanisms

• Coverage of guidance the payment application vendor is expected to provide to customers and resellers/integrators (see PA-DSS Implementation Guide later in this document) to ensure

  1) customer knows how to implement the payment application in a PCI DSS- compliant manner and

  2) customer is clearly told that certain payment application and environment settings may prohibit their PCI DSS compliance.

  Note that the payment application vendor may be expected to provide such guidance even when the specific setting

  1) cannot be controlled by the payment application vendor once the application is installed by the customer or

  2) is the responsibility of the customer, not the payment application vendor.

• Coverage of all selected platforms for the reviewed payment application version (included platforms should be specified).

• Coverage of tools used by or within the payment application to access and/or view cardholder data (reporting tools, logging tools, etc.)

(data from https://www.pcisecuritystandards.org/documents/pa-dss_v2.pdf)

Answer 3

if your application touches the payment data, it's within scope for PA-DSS. Some POS solutions pop up a separate window for payments that fall under the 3rd party app. The 3rd party and attached hardware touch the payment, and send the response code back to the merchant application so you can complete the sale. This pulls PA DSS out of scope. PCI DSS is always in scope in some fashion, but the burden can be reduced with 3rd party payment apps. Standards are continually evolving.

Answer 4

This is far too long to add as a comment so I am adding it as another answer here to my own question just to provide more information...

I have been told that it is not possible for a software system to be pci dss compliant. I have been told that PCI DSS compliance includes the total merchant environment including the network infrastructure, virus scanning, internet access limitations of servers holding cardholder data and more. It is my understanding that a software system, as its own part of certification or in adhering to the standards can only be pa dss compliant. At least, this is my current personal understanding anyway.

The issue with the pa dss requirements for software developers and software companies is that there is no appropriate definition of the word "transmitted".

The standards say:

"PCI DSS applies wherever account data is stored, processed or transmitted"

Well, based on that, we are not storing any card holder information at all, we are not processing any card holder information and we are not transmitting any information across a network or the Internet.

The problem is that "Transmitted" can literally be taken to mean anything and it needs defined appropriately. Moving data from one byte to another could be transmitted, moving it from one application domain to another, moving data across a local network or moving across the internet itself.

In reading the standards, I am under the impression that the people who wrote these standards for pa dss compliance are very unfamiliar with software and that their actual intent was to have the term "transmitted" mean to move data across a network or the internet, which of course we are not doing.

I do not believe they meant "transmitted" to mean, don't move data from one memory address location to another or do not pass data to a pa-dss compliant dll library.

I would hope that because we are not storing, processing or transmitting data over a netowrk or the internet that we would not be expected to pass a $20,000 certification just so that we can call a PA DSS secure dll library to process our cards.