Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 768
  • Last Modified:

PCI Compliance for shared hosting and other web site environments

Can someone explain to me how it's possible that places like PayPal Pro and Authorize.net state that they require their customers to be PCI Compliant when from what I can tell most people taking credit card information are not PCI Compliant?

From what I understand, one of the core aspects of PCI Compliance is that the web server and database server have to be physically separated by a firewall (on different physical servers).  99% of the websites out there taking credit cards are just using a shared hosting environment like GoDaddy, which is clearly not PCI Compliant from what I can see.

I have a client who needs to be PCI Compliant to use PayPal Pro, and it's going to cost a lot of money to do that.  I'm certain that most people taking credit cards do not have two different dedicated servers running their website.

How is this possible?
0
jbaird123
Asked:
jbaird123
  • 5
  • 3
  • 2
1 Solution
 
aleghartCommented:
That's true if you are storing CC info in the database.  For small sites like GoDaddy or others, there is an API that drops info into a cart/gateway, which processes the payment.  The CC data is not supposed to be stored.

The biggest question is why do you need to store credit card information?  I don't know of a sound reason.  I hear reasons like "that's what we always do", and convenience for the customer, or ability to bill without asking the customer for CC info again.  But, convenience is the opposite of security.

Even repeat billing can occur from a single transaction.  Authorize (and posssibly others) allow you so submit past transaction data without the CC to instigate the next billing.  Works for subcriptions or split payments, IIRC.  Look for ARB (automated recurring billing).

I've not heard that there must be a physical firewall.  Firewalls are software (firmware) anyway.  So, Server1 has it's own firewall running.  Database1 has it's own firewall running.  That's only two pieces of hardware...

The wording says, "1. Install and maintain a firewall configuration to protect cardholder data"

"Configuration" is a loose word.  In the most literal interpretation, I'd put up two layers of drywall over steel studs with rock wool insulation.  That's a standard firewall that would protect the server.
0
 
jbaird123Author Commented:
I'm not sure we need to store CC info in the database (in fact I doubt we do).  

So - my question is what is really required for PCI Compliance if you're not storing Credit Card info?  PayPal Pro requires this compliance regardless of whether you're storing CC info or not.  What do I really need to do to ensure I'm PCI Compliant?  Do I need my own dedicated server?  How do all of these mom-and-pop shops exist online - I'm sure they're not PCI Compliant.
0
 
aleghartCommented:
What specific requirements?  And, what specific products?  Are you going to use a payment gateway like Payflow Pro?  Or are you an actual service provider to PayPal?
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

 
aleghartCommented:
To be clear, protection is required if you store the PAN (primary account number).  When you store the PAN, you must also protect the following:  Cardholder Name, Service Code, Expiration Date

If you don't store the PAN, you don't need to protect the above data, according to interpretation of the guidelines.  Would be foolish not to...but if you don't have the PAN, then PCI does not apply to you.

That's why most people use a secure connection to a gateway, and hand everything off.  It's up to the gateway (like PayPal/Payflow) to keep up PCI compliance.  They have the PAN, not you.

See page 5 of v1.2.1.  It's titled "PCI DSS Applicability Information"

https://www.pcisecuritystandards.org/security_standards/download.html?id=pci_dss_v1-2.doc
0
 
Dave BaldwinFixer of ProblemsCommented:
When I had to do this with Authorize.net, the simplest solution was an SSL encrypted page for the form with the credit card info that posted to a PHP page that immediately posted to Authorize.net over another SSL secure link.  Their information did say that PCI compliance was required.  I believe that method is PCI compliant because the credit card info was never exposed or saved/stored.
0
 
jbaird123Author Commented:
Thanks for this information.

I'm building a website for my client who wants to use PayPal Pro for accepting credit cards, and possibly Paflow Pro for ACH transactions.  It's a subscription based website, so transactions must be processed monthly (and annually for customers who opt for an annual subscription).  I'm not a service provider to PayPal.

It sounds like you're telling me that as long as I'm not actually storing the CC number, I don't have to worry about PCI - correct?

The reason I'm asking is because a PayPal Customer Service Rep told me today that I needed to be PCI Compliant regardless of whether storing CC info or not.
0
 
Dave BaldwinFixer of ProblemsCommented:
Your code needs to be PCI compliant in that you don't expose the info to unauthorized people.
0
 
aleghartCommented:
>It sounds like you're telling me that as long as I'm not actually storing the CC number, I don't have to worry about PCI - correct?
Yes.  But, IANAL.

>...a PayPal Customer Service Rep told me today that I needed to be PCI Compliant regardless of whether storing CC info or not.
Funny...you can sign up for Payflow without filing a compliance certification scheme....just give them your credit card number to pay the fees.  Ironic?

The crux is, you should never have the data.  The shopping cart should pass the info to the gateway directly.  No storage.  If your solution does this, then you should be fine.  If you're doing millions of dollars, then I'd invest in legal counsel and/or a "PCI-compliant"-labeled ecommerce partner.

Don't worry, it's not just you.  It's a very grey area, even for people in the industry.  There are actual studies for cost justification of actual compliance and follow-through versus accepting losses due to litigation.
0
 
aleghartCommented:
>I believe that method is PCI compliant because the credit card info was never exposed or saved/stored.

Authorize.net has a few ways to handle that:
  • SimpleCheckout handles single-item purchases by taking the transaction to Authorize.net's servers.
  • SIM - server integration method - also takes the transactions to Authorize.net's servers
  • AIM - advanced integration method - transaction occurs on your server, requires SSL to communicate with Authorize.net
Of these three, only AIM requires you to use SSL and PCI-compliant software.

See here.
0
 
Dave BaldwinFixer of ProblemsCommented:
Actually, I was using ARB over SSL.
0

Featured Post

How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

  • 5
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now