cancel
Showing results for 
Search instead for 
Did you mean: 

Question on PCI Compliance ...

Hello.  I have a question on PCI compliance for my clients.  Auth.net recommend using the AIM connection method.  They claim this is the most secure method.  However, after reading the PCI self-assessment questionnaire (OHHH BOY), I am not so sure.  Basically, the AIM method seems to leave my clients more vulnerable since they are capturing the cc on their server.  Since the client server captures the cc information, doesn't the server have to be PCI compliant?  This doesn't just mean running a scan -- PCI compliant servers cost hundreds of dollars per month (per client)! 

 

Maybe I am missing something.  As I read the PCI paperwork and self-assessment questionnaire, I get the feeling the cc companies are putting so many requirements on small e-commerce businesses. 

 

What do you think?

 

Mona

focuswebtech
Member
Member
34 REPLIES 34

You have to worry about PCI compliance if you handle credit card data.  But if you use AIM properly, you can comply.  I disagree that using AIM, in and of itself, leaves a merchant vulnerable. 

Steve

After reading and researching, my understanding (and what I am telling my clients) is if you use AIM and your web server/hosting is NOT PCI compliant, you are vulnerable.  Even if use an SSL to transfer the data, that is NOT enough.  To remove the requirement for a server to be PCI compliant, you must send the consumer to a third-party site for the entire checkout process.

 

Per http://www.neospire.net/business.solutions/pci.dss.misconceptions.php, here are a few of the biggest misconceptions about PCI compliance:

 

  1. Since I don't store credit card information, I don't have to be PCI compliant

    FALSE. The PCI DSS does not just apply to the storage of credit card data but also to the handling of data while it is processed or transmitted over networks, phone lines, faxes, etc.  While not storing credit card data does eliminate some compliance requirements the majority of the controls dictated by the DSS remain in effect. The only way to avoid PCI compliance is to transfer the risk entirely to someone else, such as PayPal’s Website Payments Standard service where customers interact with the PayPal software directly and credit card information never traverses your own servers.

    PCI Compliance Guide- Legal rights and responsibilities
    PayPal PCI Applicability - https://www.paypal.com/pcicompliance

  2. I use PayPal/Authorize.NET therefore I don't have to be PCI complaint

    There are certain payment products that do transfer the burden of PCI compliance to the payment services provider (e.g. PayPal’s Website Payments Pro) however they require that a consumer be forwarded to the payment provider’s servers to complete their order. If your website integrates with PayPal via an API then you are still liable for PCI compliance since your servers capture and transmit the credit card data first.

    PayPal PCI Applicability - https://www.paypal.com/pcicompliance

That list of misconceptions is from a hosting provider which has a vested interest in scaring you away from other hosts.

 

Get the information from the horse's mouth PCI Security Standard Quick Guide and pcisecuritystandards.org

Steve

Actually, that same list is printed on many different sites.  Here it is again on this site:

http://www.focusonpci.com/site/index.php/Articles/pci-misconceptions.html. 

 

Also, I have read the PCI standards and the SAQ.  My understanding is that what I state above (AIM is NOT compliant if your host is not compliant).  I guess that is why I am asking the question.  Do you have any specific resources that contradict that?  I would LOVE to be wrong here -- it would make things much easier.  But, I can not find a way around the host being PCI compliant, running in a PCI compliant data center, if you want to use AIM.  

 

Where does it say otherwise? 

 

Mona

Mona,

 

I agree that if a host's environment doesn't meet the requirements of PCI, then you're not in compliance.  But I don't agree that using AIM is risky just because the host doesn't make a statement of PCI compliance.  Most commercial hosts do meet the requirements, such as establishing a firewall, having secure physical access, etc.  The PCI standard has an appendix A addressing shared hosting.

 

I will comment that I do not claim to be a PCI expert, but I do think that a merchant using AIM can claim conformance to PCI on most hosting services (assuming reasonable care is taken.)  At least as far as my client is concerned, the PCI standard highlights areas I know we still have to address before we can claim, with a straight face, that we conform.  My work in that area is not done yet.

Steve

Is anyone here from auth.net that can shed some light on this issue?  Is AIM compliant on a shared server?

 

Mona

I think I'm with hotslots here.

 

From the PCI:

 

PCI DSS Applicability Information

(table, other information)

then towards the bottom of the page:


PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.

 

Ok, we're not (hopefully) talking about storing credit card data when using AIM, and  Authorize.Net is doing the processing once they get the data, AND they are the ones storing any sensitive authentication data.

 

Transmitting? Well, perhaps, but if you try to make the argument that any transmission of the CC data in and of itself triggers the need for PCI DSS then every single piece of equipment involved ( the customer's machine, routers, backbones, each 'hop' machine in the path, etc.)  needs to be PCI compliant...So even SIM is not compliant because the customers machine is 'transmitting' data over the net and that process is (almost certainly) not PCI compliant.

 

That's a bit far fetched, and reading through the PCI guidelines it seems clear (to me) that their focus is on servers/machines that actually store and process the information, not the incoming feeds.

 

If I'm wrong, and transmission of data means ANY transmission of sensitive data, then e-commerce on the web is effectively dead and we might as well do something else to make a living... :-)

 

my $.02

 

Steve

SteveMay
Contributor
Contributor

I know this is an older thread, but I've had some of the same questions and after reading a lot of documentation on PCI-DSS and PA-DSS, I've found the helpful clarification below (this is from https://www.pcisecuritystandards.org/pdfs/pci_pa_dss.pdf).  From this excerpt and the text surrounding it in the document, I conclude:

 

- If you are the developer *and sole operator* of a SaaS-based integrated payment application - see in particular point 1 below, which distinguishes SaaS from shrink-wrapped software (SwS?)

- And your application does NOT store sensitive cardholder data (though it may transiently receive and retransmit such data to a payment gateway like Authorize.net, as long as it destroys/does not persist the data after the transaction is processed)

- And your application IS NOT sold/licensed to any other entity to deploy or operate it

- And your application and its hosting/networking/security environment is PCI-DSS compliant (there are various compliance levels depending on your transaction volume, etc., but many compliance levels can be achieved thru a self-assessment questionnaire that is not too onerous)

- THEN PA-DSS does not apply to you.

 

however, you still are on the hook for PCI -DSS compliance, though for most small businesses that will probably put them in the category that allows them to fill out the self assessment questionnaire and possibly require external network scans.

 

anyone getting a different reading from this?

 

armando

 

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. 

You are right. The server or computer you are working on needs to be PCI compliant. 

bethshady
Member

If you use AIM, you're in scope for PCI. Many many developers (including several on this thread) wishfully think that they won't be in scope if they merely transmit the card data onward to Authorize.net using the AIM api. 


All of those developers are wrong under the current PCI rules. Since the card info is transiting your server, a bad guy could break into your server or into your software and steal the card info as it flys by. Doesn't matter how unlikely it is, you're now in the scope of PCI.


To use Authorize.Net and stay out of the PCI Scope, use integration methods SIM or the new DPM -  Direct Post Method. Both keep your server out of scope.