I have been asked to set up some registration forms for clients that will take payments, similar to this site (https://www.martialartstechnologies.com/register?tournamentID=82). I am a reseller for Authorize.net, but I find it hard to sign clients up sometimes after they find out they need to get PCI compliant. I was thinking of creating one site domain that is PCI Compliant and then running each clients registration page in their own personal subdomain. If I do this, will the PCI compliance on the domain become invalid for each subdomain, or will it still be covered?
What are your clients doing that needs such a high level of PCI compliance that it’s a burden? With a standard authorized.net integration there should be a need for basic security checks, ssl, but nothing sensitive retained to warrant any of the painful parts?
As for your question changing domains will negatively impact conversion unless you are more trusted than the underlying vendor. Thus it’s not a good idea when avoidable.
Well it seems to depend on the merchant account provider. I had to go through PCI for my merchant account because they said they required it, but the last person I signed up only needed an SSL and privacy policy. And is not that its a huge burden, but even the low level compliance app takes a bit to complete and for something like a once a year tournament, they might not want to pay $100 a year for PCI.
You’re in a grey area here from what I can tell and you may want to consult a QSA for the proper answer on it.
PCI is required for all merchants and has been for several years. If there’s processors that are not requiring it, they’re taking a fairly substantial risk because associations dumped liability for non-compliant level 4 merchants on them. You’ll still find some as you suggested, but it is required, and most processors require their merchants to be prove compliance or get compliant through whatever QSA they outsource to.
However, if I’m seeing this correctly you’re not technically the merchant, so you may be subject to PA-DSS, which is an entirely different animal. Since you’re providing the service in which your application will have access to full card information as it’s entered by the merchant’s customer, and the merchant or end-user doesn’t have the ability to prove that the application is secure, you are tasked to prove compliance. A few years ago, you could use PABP (best-practices) and have a compliant application but as of now PA-DSS is required and is enforced by almost all processors.
On January 1, 2008, Visa implemented a series of mandates to eliminate the use of vulnerable payment applications from the Visa payment system. These mandates require acquirers to ensure that their merchants and agents do not use payment applications known to retain sensitive cardholder data (i.e. full magnetic stripe data, CVV2 or PIN data) and require the use of payment applications that are compliant to the PA-DSS.
Here’s a guide on Visa’s site: http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html
Anyway, I would at least consult a QSA to see where you stand in all this. You could also talk to whatever processor you are working with. Most processors are less than proficient in understanding PCI, even though they’re tasked at policing it, so a QSA is where I would start.
@jestep
Thanks for your response. You are correct in that it’s tough to get answers. When I talk to Authorize.net they say to contact QSA also. I called Control Scan and they said yes, everyone needs it, but i thought “Of course their gonna say that because they want to sell.” I use something called Gravity Forms which has an Authorize.net addon, when I asked them they said only thing requires is SSL. If my VPS server is PCI compliant from Hostgator and we aren’t storing info, its just passed to gateway over SSL, why does the domain need PCI also?