• Point of Sale Payment Application System Integrators: What is “Out of Scope?”
  
  Before I take off on this one, I have to warn you that because of the nature of various payment applications, this article is targeted solely at our own Carpé Charge product. I say this because in most blogging environments, while there may be a theme or tone that lends itself toward its owner’s biases or products, the course of blatant “marketing” is (IMHO) reserved for other settings. That said, this particular article could not be written in such a manner and due to the stickiness of the topic, had to become more of a “public answer” to a topic that comes up often in our conversations. Whether you’re interest is in our product or not the subject is important none-the-less and can be applied in any conversation within the scope of its context.
  
  
  The rules of the PCI council have been accused of rivaling the clarity of Sanskrit law and thus, most of us in the industry are forced to rely on interpretation of our PCI auditors to help decipher the language. However, it is important to note that interpretation of the rules of play are only as good as their question. Simply stated: ask the wrong question = get the wrong answer.
  
  As elementary as this may sound, please note, the majority of meetings I have within the card payment industry begin with a 10 minute (or longer) volley between my audience and I decoding what it is the other does. Sometimes it can be painfully slow to get a grip on one another’s position in the market. This is not limited to any one industry demographic. I’ve had seasoned pros who thought we were one thing when we were another and vice-versa. So when people start asking questions about PCI rules and codes, my hunch is they are not asking enough questions, the right questions or meeting their responder with a mutual understanding. In the end, the one with the answers is giving an answer to an ill former query.
  
  Case in point: I have run into several companies lately who would have bet their mother and the farm that their company had to go through PCI certifications in order to use an already approved PCI application.
  
  This is not necessarily true.
  
  What I found was that every single time, the company who thought they had to pay the fees for certification were mis-informed because they mis-asked and further more mis-interpreted what they heard.
  
  So here it is. In simple terms, how we work…how we work with you…and what the PCI has to say about it..
  
  
  If you are a POS software developer…
  And you do not have a PCI certified payment application in your software…
  And you want to have one…
  You can integrate to Carpé Charge via our free API…
  And you will be OUT OF SCOPE of PCI-DSS….
  Because…Carpé Charge handles 100% of the transaction. From the moment the card is swiped – through the return of the authorization. And because your system does not touch the data…you are NOT in violation of the code.
  Lastly, our integration to your POS can be completely transparent. What this means to your clients is they will see the look, feel and design of your system as you intended it to be, while our product silently handles 100% of the card payment transaction process.
  

As a POS Developer, VAR or System Integrator - you should be concerned with non certified payment applications and do everything possible to maintain seperation between the POS software and the payment application. A payment applicaiton that removes the POS system from scope is the right way to go.

Just to cover my tracks, below is the mumbo-jumbo straight from PCI. Read it if you like, or refer to the cliff notes above. And remember these words: Our application handles the transaction 100%. Your POS software does not have to touch any credit card transaction data!

________________________________________________________________________
The following excerpt was provided by DRG (Digital Resource Group), a certified PCI auditor and is from the PCI Requirements and Security Assessment Procedures Version 1.2.1 July 2009.

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 authorization 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:
Note:
All validated payment
application products must
not be beta versions.
􀂃 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 apply to payment applications provided in modules, which typically includes a “baseline” module and other modules specific
to customer types or functions, or customized 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 “software as a service” payment applications include:
1) 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.
2) Virtual terminal applications that reside on a service providers’ site and are used by merchants to enter their 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 fraudmonitoring,
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
PCI PA-DSS Requirements and Security Assessment Procedures v1.2.1 Page vi
Copyright 2008 PCI Security Standards Council LLC July 2009
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”
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.
􀂃 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.
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):
􀂃 Operating systems onto which a payment application is installed (for example, Windows, Unix)
􀂃 Database systems that store cardholder data (for example, Oracle)
􀂃 Back-office systems that store cardholder data (for example, for reporting or customer service purposes)
Note:
PCI SSC will ONLY list
applications that are
payment applications.
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, and 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 DSScompliant
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)