Authorize.Net API questions and help with your payment integration.
Authorize.Net API questions and help with your payment integration.
09-17-2009 01:39 PM
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.
09-17-2009 04:11 PM
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:
PayPal PCI Applicability - https://www.paypal.com/pcicompliance
09-17-2009 04:22 PM
09-17-2009 04:48 PM
Actually, that same list is printed on many different sites. Here it is again on this site:
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?
09-17-2009 05:10 PM
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.
09-19-2009 11:20 AM
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... :-)
06-15-2010 06:30 PM
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?
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
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.
08-17-2011 11:08 AM
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.