New credit card security standards regarding PA-DSS Compliance

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.

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)


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.

Tags:

Pci Dss

Compliance

Recent Posts