2

I am creating an "average" e-commerce website (using drupal and ubercart if that matters). I've read about pci compliance in the past, and that's why I'm wondering how I can see what applies to my situation. I'll probably be going with "rackspace cloud servers", though we might end up going with the amazon cloud. It doesn't seem like there should really be any requirements as long as I have a working ssl certificate along with not storing the credit cards on my server. If I'm using authorize.net or something similar, it seems like most of the compliance will be on their part.

When do I need to learn more? (Before I choose a host and get a server all ready to go)

How can I learn more?

Any general advice/tips?

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
Matthew
  • 1,859
  • 4
  • 22
  • 32

2 Answers2

7

My advice (having gone through full PCI compliance audits) would be to use a 3rd party payment processor unless you have significant volume, expertise and manpower in-house. This should reduce your exposure to SAQ-A which means that you need to simply fill out a questionnaire.

If you are processing cards on-site (i.e. through your software / servers / network etc.), then you're most likely SAQ-C and you'll need to jump through a bunch of hoops.

Find a payment processor that is PCI compliant that will take full ownership of the transaction. i.e. you would redirect to their website to offer payment.

What payments processors are PCI compliant, are relevant in your location, for the types of cards you want to process etc. can be very specific to you. That's a research task for yourself.

Philip Reynolds
  • 9,799
  • 1
  • 34
  • 33
1

You only need PCI if you are handling credit card numbers yourself. The smart choice would be to leave anything regarding credit cards and handling of data from them to your PSP (Payment Service Provider) and only handle customer name/address and such on your own site.

Frands Hansen
  • 4,657
  • 1
  • 17
  • 29
  • Alright could you be more specific about Payment Service Providers? I don't want to redirect the user to another website. Does authorize.net fulfill the PSP role? – Matthew May 30 '11 at 19:04
  • Unfortunately that's not correct. Your business needs to be PCI compliant. Using a 3rd party processor does reduce the risk, effort and exposure, but it does not exclude you from compliance. http://www.practicalecommerce.com/articles/1439-PCI-Exec-Suggests-Payment-Outsourcing-for-Smaller-Merchants – Philip Reynolds May 30 '11 at 19:05
  • The best instructions that I can find are http://www.ubercart.org/paypal. Website Payments Standard seems like the safest option: if customers are redirected to PayPal to enter credit card information, you _shouldn't_ need PCI. Trying to achieve PCI-compliance for small merchants looks like a nightmare. – user775598 May 30 '11 at 19:16
  • -1 for inaccuracy. If your customers pay with a credit card, then you have to be PCI compliant. Farming this out to a 3rd party means that you have a heck of a less amount of work to do, but that doesnt mean that you still dont have to be compliant. – Josh Brower May 30 '11 at 23:34
  • @Josh Brower doesn't it depend on the payment provider? For example, if you outsource *all* payment functions to Google Checkout, you do not need to complete a PCI SAQ – Cocowalla May 31 '11 at 10:49
  • @Cocowalla see here: http://www.pcicomplianceguide.org/pcifaqs.php#8 "Q: Do organizations using third-party processors have to be PCI compliant? A: Yes. Merely using a third-party company does not exclude a company from PCI compliance. It may cut down on their risk exposure and consequently reduce the effort to validate compliance. However, it does not mean they can ignore PCI." – Josh Brower May 31 '11 at 13:08
  • I'm pretty sure it still depends on the *type* of payment processor you use. My understanding is that if you use an *entirely redirected payment solution*, then you do not need to be PCI compliant (e.g. Google Checkout) – Cocowalla Jun 01 '11 at 11:09