How is 'processing credit card data' defined (PCI)?

Question

If i have a web application and i receive credit card data transmitted via a POST request by a web browser over HTTPS and instantly open a socket (SSL) to a remote PCI compilant card processor to forward the data and wait for a response, am i allowed to do that? or is this receiving the data with my application and forwarding it already subject of "processing credit card data"?

if i create an iframe that is displayed in a client browser to enter cc data and this iframe posts the data via HTTPS to remote card processor (directly!) is this already a case of processing credit card data? even if my application code 'doesnt touch' the entered data with any event handlers?

i'm interested in the definition "credit card data processing". when does it start to be a cc data processing application? can somebody maybe point me to that section in PCI-DSS standard that clearly defines when you start to 'be a processing application'?

Thanks,

Answer 1

Its a good question, and I'd love to hear some authoritative answers - either from someone directly representing the PCI-DSS or at least a QSA with access to PCI members.

My unauthoritative answer would be that the webserver that hosts the iframe would be in scope for PCI, and you'd be classed as a service provider. This is based on my interpretation of the PCI standard, where the glossary states:

Service Provider Business entity that is not a payment card brand member or a merchant directly involved in the processing, storage, transmission, and switching or transaction data and cardholder information or both (*1). This also includes companies that provide services to merchants, services providers or members that control or could impact the security of cardholder data (*2). Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded (*3)

*1. You're clearly not a payment card brand (such as Visa), neither are you a merchant (to whom you're providing this service)
*2. This is pretty clearly your role, as providing a service
*3. Unfortunately, I dont think you meet this exclusion, as you have access to application layer data.

The good news is that the approach you've taken is probably the best you can do to minimise your headaches.

Ideally then you'd segment this server so that access to a wider (internal) network is very restricted. Ensure that the only 'application' the webserver provides is this iframe (ie, dont run any other webpages from the server). Ensure that the logging that the server/iframe/etc generate doesnt contain any card related data

Unfortunately I belive it does mean that a QSA needs to be involved, as you are processing web transactions.

Answer 2

You transmit the data, even if you don't do anything with it yourself. Therefore, you do fall under PCI compliance rules.

PCI DSS v .2.1, Page 5, under PCI DSS Applicability Information:

PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.

PCI DSS section 4.1, for example, requires encryption when transmitting over public/open networks, which you have covered with SSL and HTTPS at both ends.

But there's not just the requirements concerning direct dealings with card data. There's also user authentication controls, such as in PCI DSS section 8.x, particularly for users with access to cardholder data or administrative capabilities.

While there are sections you can ignore since you don't store the card data, there are other sections that deal with things like network security, firewalls, antivirus, access control, monitoring and tracking, testing, etc.