My firm is moving into the realm of eCommerce for our clients and I currently have a client that has a physical retail store that now wants to add an online presence. I've done much reading into the issue of pci dss compliance (most of which was quite frustrating reading) and I have some concerns that I'm hoping people here can help me address.

At this point the client is ok having payments processed via a third-party processor such as paypal. From my LIMITED understanding of PCI compliance, in theory, as long as the customer processes the credit card part of the transaction on PayPal, my client generally (minus a few details) in the clear in terms of PCI compliance. This is what the general consensus seems to be around what I've read.

The problem that I have here is that I've been unable to find an authoritative source that will verify that if my client has "X-brand third-party payment processor" (e.g. paypal web payment standard or the like), that they will be in compliance. All I can find is a lot of forums where people say "I'm pretty sure that it's ok" or "It should be fine..".

It would be unacceptable for my business and my client if I said I was "pretty-sure" that the paypal website payments standard I setup for them was PCI compliant, and then I turned out to be wrong.

As the development firm I'm not interested in taking on the responsibility or liability of a PCI compliance problem; I want to find a reputable company that I can work with the client that will basically take the reigns and "guarantee" PCI compliance so I'm not playing what appears to be the "PCI-guessing game" that I see so much. This way, if an audit ever came knocking, the client could have some kind of authoritative documentation that verifies that they've been doing what they're supposed to be doing.

Because of the potential fines involved with being out of compliance, I'm currently looking to see how everyone else has solved this problem. Can anyone recommend a third-party vendor that will do for PCI compliance what a hosting company does for a client with a managed server? (e.g. send us a check each month and we'll make sure everything works and is what it needs to be).

Any advice is much appreciated.
Thanks,
R

I too am preparing to launch my own eCommerce store. To boil it down, PCI compliance lies in the hand of the credit card processor. That is to say, if you manually process all of your own credit cards, you will need to be PCI compliant. If you use a third party vender for CC processing, they will need to be PCI compliant.

Depending on your country, you may want to look for a local CC processor. The big three IMO are Paypal, Google Checkout, and Authorize.net. I live in America and I was able to get a better rate with a local Authorize.net dealer than I was with either paypal or google checkout.

Hope it helps.

I'd normally expect to see a PCI compliance statement on the 3rd party processors website
For example: https://www.paypal.com/pcicompliance

Why not go ahead and make the site fully PCI complaint? They will need a secure server,(HTTPS), and a certificate. I think you would be better off going that route, than guessing on 3rd party compliance.

To boil it down, PCI compliance lies in the hand of the credit card processor. That is to say, if you manually process all of your own credit cards, you will need to be PCI compliant. If you use a third party vender for CC processing, they will need to be PCI compliant.

In all cases, the responsibility for PCI compliance lies with the merchant, even if using a 3rd party processor. The method of attesting compliance changes a little but the responsibility does not shift.

Why not go ahead and make the site fully PCI complaint? They will need a secure server,(HTTPS), and a certificate. I think you would be better off going that route, than guessing on 3rd party compliance.

There are a few other things required to be PCI compliant than a ssl cert and a secure server. Based on the compliance type, there are over 200 different line items on the checklist that must be adhered to. Firewalls, segmentation, log monitoring and retention, HIDS, file integrity monitoring, proper documentation, change management and........

Using a 3rd party is the most economical method available when compared to around $1k per month to build a solution that provides nearly all aspects required by PCI for a type 5 merchant.

The governing body of PCI is

https://www.pcisecuritystandards.org/security_standards/vpa/

This will give you most of the PCI info available.

Using PayPal may take some of the security requirements off of the merchant, but certainly not all of them. To evaluate what you need to do security wise look at the Security Assessment Questionnaires. You have the easiest (SAQ-A) to the harder ones like SAQ-D. The one you need to fill out depends on how your are processing credit cards. Look through this and find out which applies to you. It is up to the merchant to make sure that all of the points that his system touches is PCI compliant. For instance, if you are using a Point of Sale System or shopping cart that is connected to PayPal or Authorize.net and the Point of Sale system is not PCI compliant AND approved, then you as a merchant are liable for the breech because by using an unapproved application, you ended up not being PCI compliant. You can even get nailed if one of your phone operators is writing credit card numbers on a post it note prior to entering it in the system--if the post-its are stolen from the trash, then--yep you guessed it--you as a merchant are liable.

Remember that you need a separate server for each role. The SAQ is extensive and can get quite tedious.

Based on an analysis of my business... guess what I was given... SAQ-D :/

Look for SAQ A on the PCI Security Standards website -- https://www.pcisecuritystandards.org/saq/docs/aoc_saq_a.doc

Unless you are hosting your own server (and even then), I would recommend any solution you select qualifies for this SAQ. The main requirement is that your site and server must never come into contact with credit/debit card numbers and you must use a PCI-DSS certified and approved third party to handle this data. SAQ A is sometimes referred to as the Paypal SAQ because they are on the board and had it defined with them in mind. Paypal (native, not the Pro version) obviously qualifies for this. A few other gateways do as well.

The disadvantage with Paypal is that the user is sent off to the Paypal site to complete the payment for an order. While other gateway providers have similar techniques, at least one that I know of ;-) all but completely hides this redirect and give you complete control over the transaction -- not simply a "get me $50" request, making true book & ship, card on file (one click), or integrated periodic (monthly) payments doable.

...... $1k per month to build a solution that provides nearly all aspects required by PCI for a type 5 merchant.


That sounds pretty cheap, what parties offer it at the price?

We work with Miva Merchant and they are partnered with ControlScan which is a company that handles PCI Compliance issues.

Since you mentioned ControlScan, this may be of interest to you...

FTC To ControlScan: Your Web Site Security Seals Are Lies (http://www.storefrontbacktalk.com/securityfraud/ftc-to-controlscan-your-web-site-security-seals-are-lies/)

Shift4sms, thanks for the link. I am shocked by this article. Pretty unbelievable stuff and I am looking into that matter and researching this. Crazy.

Great link Shift4. Interesting stuff!

You may want to find a copy of self-assestment questionnaire form which is required for the PCI compliance, and prepare yourself accordingly. Something like this: https://www.pcisecuritystandards.org/saq/index.shtml

When they say computers or systems in those forms, they usually refer to the machine where the transaction occurs. This can be your web server or PayPal's server. If it's your server, they may question if you are managing it or it's a fully managed by an ISP. In one case, I had to clarify that my server was not colocated and it was fully managed by the company XYZ and it was secure behind their firewalls so that one or two questions wouldn't be applicable. We, however, are always responsible for the web application (access logs, application bugs etc)

Most of the concern is about stealing ones credit card and/or identity. If you are using a 3rd party such as PayPal and Google Checkout, then your responsibility will be less than other merchants like Amazon. Also they have tougher restrictions on those whose yearly sales reach to certain amount.

Usually getting a 3rd party service like ControlScan (but not ControlScan) can be useful as they eagerly scan your web site and try to find open holes. And it's easy to manage those PCI compliance forms too. I personally use McAfee, but there are others that can provide the same service.

Both VISA and Mastercard publish official lists of Compliant third parties and describe the services they are compliant for:
Search on google under mastercard compliant service providers, visa inc compliant service providers - Global List of PCI DSS Validated Service Providers, VISA Europe AIS Certified Service Providers.

Although it does not get you out of the compliance, if you wan't the least fuss you best stick to a "Hosted Payment Page" soloution. This way you do not see any of the Cardholders Data and cuts down on a lot of work. You still have to take the steps as mentioned above in the PCI Questionnaire to gain PCI acceptance.

Most of it is just simple common sense and every Business should be implementing the requirements. If you are serious in the first place when running a Business, you should already have these steps in operation well before all this PCI Compliance came into force.

Am.....very well said.

At the end of the day, ampcs is correct in that it is indeed everyone's responsibility. The practical reality when it comes to liability is that any fines for a security breach would originate from Visa/MasterCard and first they would most likely be levied at the merchant's acquiring bank followed by the ISO/MSP and then the merchant. That doesn't preclude a more direct liability path, however, in the event that civil suits were to be filed.

From an implementation standpoint for a merchant, there are really three basic ways to go about it.

You can opt to do a full PCI compliant implementation from the ground up, utilizing a variety of 3rd party vendors and your own IT staff (preferably with a skillset in this area already in place but if not it can still be done, albeit with a definite learning curve) and control it 100%. The benefit is that you control everything, the downside is that it will be substantially more time consuming and expensive.

The second way is to use a 3rd party service and completely re-direct your payment pages there. This is less time consuming and less costly but from an aesthetic standpoint, a user attrition/session control point of view - it is much less preferable.

The third way is to use a hybrid approach where you can get all of the benefits of controlling the data & the billings while still presenting the end user with the perception that they are still on your Web site... while simultaneously having all payment data entered bypass your server/network/sofware and go directly to the PCI certified gateway.

The third method eliminates ANY flow of cardholder data from ever touching your network and it eliminates a vast majority of the steps that you would otherwise need to contend with to ensure PCI compliance.

Keep in mind that based upon your specific merchant processor and your PCI Level as a merchant, you may still need to run an external scan or fill out an SAQ but the heavy lifty will - in this scenario - be delegated along without the normal downsides.

CDGCommerce is correct, but there's a little more to it. If you are using one of the most popular shopping carts (well, like Magento) the payment gateway has to support the cart. So even though some gateways can have a "one-step approach" to PCI, don't expect it if you are using Magento as a shopping cart.