Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

migrated from May 25 '11 at 20:54

This question came from our site for professional and enthusiast programmers.

Hi @Matt, welcome to the site, and thanks for the great question! – AviD Jun 5 '11 at 9:12
up vote 9 down vote accepted

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.
share|improve this answer
accepted as the best answer at this time. – Matt May 26 '11 at 19:46

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
please add this as an update to your question, not as an answer. – AviD Jun 5 '11 at 9:06
Now, to your points - the issue is that you are processing it, by accepting the CHD from the user. It is handled by your code, so your code needs to be PA compliant. It's as simple as that... Think of the alternative, you could be simply getting the CC's, and writing them to a file, before sending it to the DLL. See why your product would also need to be compliant? – AviD Jun 5 '11 at 9:09
Here's a solution, though - the "secure" 3rd party processor DLL should offer a "secure" UI to accept the CHD directly. I've guided many a vendor in implementing this solution.... That way, the CHD goes directly into their own code, and never touches your bits. (Of course, verify this with your own PA QSA). – AviD Jun 5 '11 at 9:10
And btw as an aside, the DSS's are very technically oriented, and they work with many in the industry to ensure that it's (relatively) on target. – AviD Jun 5 '11 at 9:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.