homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / WebmasterWorld / Ecommerce
Forum Library, Charter, Moderators: buckworks

Ecommerce Forum

This 31 message thread spans 2 pages: 31 ( [1] 2 > >     
"Enough" vs. "Too Much" PCI Compliance

 12:31 am on Sep 23, 2009 (gmt 0)

I am aware that this topic has been discussed in many threads, but I have yet to find a consensus regarding the following issues. There seems to be a lot of speculation, hearsay, and just play misinformation floating around on both this site and other forums. I would like to engage those who are currently accepting credit cards on their sites in this thread (I know a lot of you reading this are), to hopefully get down to the nitty gritty, and finally reach a consensus on these key questions that keep getting asked again and again:

1) If you simply transmit CC data to your payment gateway (lets use PayPal via Web Payments Pro for these examples), do you need to take exactly the same rigorous measures as if you were to store the data in your database? Or are there parts of the compliance that you can "leave out" so to speak? If so, what are they?

2) Is having a 128-bit SSL certificate (plus bulletproof code) enough to be able to collect the CC data and immediately transmit it to PayPal (again through a secure connection), assuming you're not storing the data?

3) Is being on a shared hosting account automatically considered "not compliant"? Are some web hosts better than others? How would one find out?

4) It seems every rinky-dink-looking website out there is accepting credit cards. Why does the process seem so common/easy for seemingly small shops, yet seem like there's so many hoops to jump through for a beginner? Is there something we're missing?



 9:57 am on Sep 23, 2009 (gmt 0)

Why does the process seem so common/easy for seemingly small shops, yet seem like there's so many hoops to jump through for a beginner? Is there something we're missing?

I imagine that some are just breaking the rules and manually processing the transactions as if they were phone orders and most use a checkout page located on their processor's secure server so they never actually see the card details themselves.


 1:28 pm on Sep 23, 2009 (gmt 0)

1. There are various levels, but you are required to be PCI compliant if you are just transmitting cc data. If you are storing, there are much higher levels of compliance.

2. No, there are a lot of measures you need to have in place. From having a PCI/DLSS compliant cart, to having your network secured, to having documentation in place outlining your IT security policies

3. No, as long as your shared hosting account can be PCI compliant then you can be PCI compliant on shared hosting. ** This one is a tricky question though

4. The reason for this is as of right now non-compliance is simply a small monthly fine (like $20) and people are dealing with it. As this gets tougher you will see small shops fold as they will either need to switch to using a boomerang provider or get in compliance.


 2:24 pm on Sep 23, 2009 (gmt 0)

ssgumby non compliance for me would be losing my merchant account with the CC processing company I use. I have no idea were that monthly fine has come from. Maybe from some of the more shady processors but the one I use it is "You have X amount of time to be PCI if you don't then your account will be Terminated".

nicu I will try to help add to the post informational value here.

First off when your contacted by either the CC processor or the Company that does the PCI for the CC Processor you will be questioned on your level of Exposure. This is used to determine what PCI Scan will be used against your server.

1- Transmitting data to a CC processor.
If you use a cart and take ANY personal information ie: Phone number, address and on then connect to the CC processor through the cart you are required to be PCI to a certain level.

If you connect to a CC processors cart and don't have any stored data then No you do not have to be PCI.

If you collect and store CC numbers and personal information then you are required Top level of PCI and are Legally Responsible for any Breach of Security and data theft with very heavy fines.

2- This all depends on if your collecting personal information in your cart then sending the data to PayPal. If you collect Personal data first then YES you need to be PCI. If your just connecting to PayPal viva PayPal buy button were nothing is collected on your end then NO

3-Shared or dedicated doesn't matter the scan is on the Server. If another site on the server has issues then that site has to fix the issue until then you will fail. Here lies the problem how do you get another site to fix a hole most can't or won't so your done. Ok so you get the other site to fix the hole and Pass well your scanned each month and another account has been installed on the server and that site causes the server to fail well here you go again. being on a shared server really won't cut it because of this.

4. ssgumby maybe correct in this but as I stated above I would have lost my merchant account if not PCI. I feel this is coming and there will be many sites that just take the risk and lie.

Case point I am now seeing more sites not using any SS connections in the cart taking personal data, cc numbers, and cvv numbers. They must be misleading the CC processor and have a terminal on their desk. I believe that are telling the CC Processor the cards are being swiped. These sites usually have a ton of fake seals and all this text saying how secure the site is but are complete lies and it is just a matter of time before legal issues arise.

I believe there will be a way to turn in these sites in the near future just as there is a way to turn in Spammers on Google. The public and Government is getting fed up with the theft of personal data and a day is coming when this type of activity will land them in Federal Court.

The hoops and loops are being put into place to stop or slow down the ability for just anybody getting a merchant account for internet processing.

Being in the business for 10 years I fully support the new regulations even though it cost me a big block of time to become PCI it really helped me tighten up my server.

[edited by: bwnbwn at 2:44 pm (utc) on Sep. 23, 2009]


 2:43 pm on Sep 23, 2009 (gmt 0)

I use First Data. Yes, non compliance in the future would cause the loss of merchant account. At this time it is simply a fine. How do I know this? Because I AM compliant but continue to fight with them to prove so. I get the fine on my account, PROVE I am compliant once again and get it removed.


 3:00 pm on Sep 23, 2009 (gmt 0)

ssgumby I use fast data as well intresting. Question you say your PCI but must be declared not PCI by fastdata can you explain this to us as I find this very important info.


 3:57 pm on Sep 23, 2009 (gmt 0)

Here is the deal, first I am using First Data.

I send them the questionairre SAQ-C .. I also submit them the quarterly scans. Every month they send a letter saying they did not receive either of these. After literally 2 hours on the phone (each month) they find they do in fact have it and refund the charge. This has happened every single month this year thus far.

I now email it, snail mail it, fax it and call to follow up to see if they got it. Even then, eventually I get the letter stating they don't have it.


 5:54 pm on Sep 23, 2009 (gmt 0)

Who is scanning your server "Security Mertics"? I did all the stuff online so there isn't an issue with this.

All this can be done online not sure why your having to do it this way.


 6:56 pm on Sep 23, 2009 (gmt 0)

No, I use Mcafee which is an approved scanner. They tried to force SM on me and I refused. There is no reason for me to use SM when I already pay Mcafee to do this service.


 7:29 pm on Sep 23, 2009 (gmt 0)

Great work so far everyone. Here's what we have so far:

1) If you're simply collecting personal information (including a CC number), you still have to be PCI Compliant, but to less rigorous standards than if you're storing the data (and by data I mean credit card number, not simply name, address, etc. From what I also understand, the "last 4" is OK to store locally, although it is probably wise to encrypt it). These standards would include mostly hardware-related network/software issues that would mostly be managed by a hosting provider. If you DO decide to store the CC data, I assume the extra precautions would involve encrypting the data, and restricting access to that data/the encryption key to need-to-know employees only?

2) ssgumby, you mention having the PCI/DSS compliant cart. If the software is home-brewed, what, exactly, would be required? It seems that, if you're not storing data, the only obvious requirement for a "PCI Compliant" cart would be to ensure that the connections between the server-customer and server-gateway are both secure. If you ARE storing data, the cart would encrypt the data. Is that all there is to it? Those issues seem rather common-sense.

3) On a shared hosting environment, in order for your site to pass PCI/DSS tests, every site on the server needs to pass? Which obviously is out of your control. Does that mean that the only option is to be on a Virtual and/or Dedicated server? Which could be out of reach for many small shops, especially if they require an additional SQL Server license. If any web hosts claim to offer PCI-compliant shared hosting, should one be skeptical?

4) I've seen people say the fines for non-compliance can be anywhere from $20 a month to $50,000 per month, plus losing your merchant account. I suppose this varies from processor to processor?


 7:56 pm on Sep 23, 2009 (gmt 0)

2. The gist of the cart certification is things such as password complexities for admins, password expirations, cross site scripting attacks, numerous other attacks, session timeout. Trust me, you dont want a home grown cart .. from what ive read the certification process is VERY expensive.

4. I've never seen a 50k fine for non-compliance, but I have seen a 250k fine for each loss of data related to Visa if you are not compliant. By "seen" I mean i've read it on Visa site somewhere. So in essence 2 stolen cc #'s would cost you 500k in fines from Visa. MC is much less.


 8:09 pm on Sep 23, 2009 (gmt 0)

nicu ssgumby isn't being fined because he isn't PCI but from what it looks like paper work incomplete due to the fact it looks like FastData can't route the paper work correctly.

Virtual hosting is pretty much the same as shared due to the fact there is more than 1 website on the server so any scripts, programs, databases everthing they have installed on the server must be able to pass as well or you run into the same issue as shared.

You pretty much have to be with a host that has shared, virtural, dedicated servers PCI or have the cart connect to a PCI Server for personal data and CC processing.

I see more ecommerce sites going this route were the website is using the host cart that is PCI. So all stored personal data is being stored with the hostng company that is PCI. The host that I have found offering this feature do not allow CC numbers to be stored as this increases the Host risk and increases the host cost to maintain the PCI status.

This route does cause a possible issue IMO as the cart url is not in the domain name as well as the Secure Certificate is in the hosting companies name.

The cost for the PCI service seems to be causing the host to increase monthly fees to cover these perks.


 8:23 pm on Sep 23, 2009 (gmt 0)


We are with First Data also. I believe that we were charged for the use of Security Metrics and did not have the option to opt-out. You might want to check and if so, have them do the scan anyway. We've been ok but feel your pain as dealing with First Data support is difficult.


 8:32 pm on Sep 23, 2009 (gmt 0)

Regarding the cart itself..
ssgumby, who certifies each cart? Is there an agency that oversees this? Is it the gateway? Or is a cart considered compliant simply be passing a vulnerability scan?

My current project requires users to be charged variable amounts each month, depending on usage. A full-fledged cart solution would be way more than what's needed. A simple interface to charge/authorize the user's card the first time, and then software to make the appropriate requests each month is all that is needed. Must of the software is already written. Should we not use it? Is there a simple cart you could recommend, which is light on features?

bwnbwn, being redirected to another url at checkout (I think that's what you're saying) would, in my opinion, damage your visitors' perception of your site. I know that any time I'm redirected to another site to check-out, I immediately abandon the sale. You may as well use PayPal Standard, be redirected to PayPal (which customers would probably trust more than XYZ Cart anyway), and save yourself all the headaches.. Unless I'm misunderstanding what you're saying.


 5:03 pm on Sep 24, 2009 (gmt 0)

I don't see this link in this thread which should answer many of your questions.

PCI Compliance Guide [pcicomplianceguide.org]

who certifies each cart?

Most gateways rely on Security Metrics site scans for determining a site's compliance and risk factors.

An aside, the cost of S.M. scanning, as I recall, is like $700 per year or more. The gateway service carries this bill (and is not likely paying a full $700 for it,) but charges you $20/month or so for being non compliant. I have clients with both FirstData/Linkpoint/Evalon (all the same) and Authorize.net, both of those are charged around $20/month for each non-compliant status.

being redirected to another url at checkout (I think that's what you're saying) would, in my opinion, damage your visitors' perception of your site.

If you have a quality SSL cert and are connected to a gateway, this is not necessary but is often used because people don't understand the technology or how to implement it.

What you do is from your site, collect the data in memory as part of the scripting process. You then make what is called a silent post using curl to post the data to the gateway and receive a response. At this point, your site has not written any data - posted it to the gateway and received a response (approved, declined, etc.)

Based on that response you now write order data to the database and return a response to the browser. All in one step, no external site navigation required.


 7:54 pm on Sep 24, 2009 (gmt 0)

rocknbil, if I could just get an account up and running tomorrow, and pay $20 a month as a non-compliant penalty, I gladly would. But I know there are bigger issues, like losing your merchant account all together (not to mention the risk of personal data being compromised).

Based on that response you now write order data to the database and return a response to the browser. All in one step, no external site navigation required.

Fortunately, the technical aspects are what I'm most familiar with- it's the procedural issues that I'm unclear about. I guess I misunderstood what bwnbwn was trying to say when he said "This route does cause a possible issue IMO as the cart url is not in the domain name as well as the Secure Certificate is in the hosting companies name."

[edited by: nicu at 8:11 pm (utc) on Sep. 24, 2009]


 8:01 pm on Sep 24, 2009 (gmt 0)

No..you didn't misunderstand bwnbwn. Most of the third party systems do just that. You start out on your site, then when it comes time to enter cardholder data, you are taken to the third party site. This is often the cheapest/best alternative for some businesses as it takes the merchants site completely out of scope on PCI compliance as no cardholder data is being entered on the site.

The downside, as bwnbwn states is that the URL and generally the site design will change when you go to the third party site which, in my opinion, will definitely impact conversion rates.


 8:13 pm on Sep 24, 2009 (gmt 0)

Exactly.. and if I was using that method (the easy method), I would probably go with PayPal, since their rates are relatively competitive, and probably command far more trust than probably any other 3rd party payment site.

But I would agree with you and bwnbwn - that's a pretty huge downside. It just gives the impression that the site can't afford to integrate payment into the site, whether or not that's true.


 8:30 pm on Sep 24, 2009 (gmt 0)

Very true, however, I have a feeling that the third party route will become VERY commonplace in the near future as PCI becomes more and more of an issue.

Many sites simply won't be able to afford the added expense and technical challenges of making sure they are PCI compliant.

One of the carts I use just setup a new system just for this. When it comes time in the purchase process for the customer to enter personal information they are taken to a third site, however the site uses my template so the look and feel are identical to my site. The URL still changes, but it's a step in the right direction.


 8:40 pm on Sep 24, 2009 (gmt 0)

An idea i thought of just now, which I really haven't put any thought into yet, but why not just load the third party site into an iframe of your own site, so the URL in the browser doesn't change? And the page on your site that contains the IFrame could be a secure page so the customer still sees the lock and feels secure. Would that raise a security exception? Do sites do this? Is this against the terms of use of checkout sites? This solution, in my opinion (and if it works), could be perfect.


 8:59 pm on Sep 24, 2009 (gmt 0)

why not just load the third party site into an iframe of your own site

Intresting thought there that would work well IMO. Putting the frame page in an ss enviorment is a really good idea nicu and I can see no reason for it not working and working well.


 10:18 am on Oct 24, 2009 (gmt 0)

One of the major UK payment gateways offers the option to frame their credit card entry page in an iFrame.

I'm integrating with them at the moment, but haven't decided whether to use the iFrame integration or their external integration.

Thing that worries me is when browsers cotton on and start popping up messages saying "the page you are dealing with isn't where you think it is".


 9:57 pm on Oct 28, 2009 (gmt 0)

I was seeing this thread and was wondering why I haven't been hammered by my merchant account for this compliance yet. So I was reading some of the requirements on Authorize.net:

Merchant level 4:

Selection Criteria:
Less than 20,000 Visa or MasterCard e-commerce transactions per year, and all other merchants processing up to 1 million Visa or MasterCard transactions per year

Validation Actions:
Recommended annual PCI Self-Assessment Questionnaire and quarterly network scan

Validated By:
Merchant qualified independent scan vendor

Note: While compliance is mandatory for Level 4 Merchants, validation is optional but strongly recommended

So while compliance is still mandatory, small shop owners can avoid a lot of the red tape of *proving compliance* by staying small.

I know that Merchant Level 4 is a volume that many of the people on Webmaster World would not bother with, but I will sheepishly admit I'm well, in that category.


 6:43 pm on Nov 3, 2009 (gmt 0)

The problem is that no small company can really afford to become truly PCI compliant (as opposed to pass an SM scan, fill in the forms etc). I'm afraid that if you read the small print this becomes obvious. And even if you are a Level 4 Merchant, the SAME standard applies even though the way that you prove you are compliant differs.

Personally, I believe every small or medium sized merchant should use a payment service provider, with all payment card details captured at their site. Although there is a fear that this will reduce orders, all the reports that I've heard are that this actually isn't the case.

I think that there are big risks for people that try to do it themselves. First, the banks are gradually upping enforcement. Eventually it won't be good enough to simply declare that you are compliant, you will actually have to do everything required. And if there's a proved breach at your site, you will pretty much be out of business.

Secondly, there a lot of nasty people out there deliberately targeting web sites to acquire card details. I don't know about you, but I don't want my head above the parapet.


 7:03 pm on Nov 3, 2009 (gmt 0)

cbarling -

What do you mean "eventually you will have to do everything required"? I currently do everything required. I don't "declare" I am compliant, I submit my quarterly scans, I submit the questionairre that is required of me. I won't get to the level of needing an on site assessor as won't other small business. Trust me, banks dont want to force too much compliance .. they make a lot of money off these small business.

As for a breach putting one out of business. First, it definitely would make an impact on business as folks would in the short term have a fear of shopping. However, people forget quickly. There are plenty of well known hacked sites out there that are still cranking away. As for liability .. you had better have several million in fraud/identity theft insurance. Its cheap and well worth it to cover you if you have losses.


 7:38 pm on Nov 3, 2009 (gmt 0)

The problem is that no small company can really afford to become truly PCI compliant

I have personally brought two one-person, sole proprietorship companies into PCI compliance, and while it cost them a fair bit, it wasn't the moon. I'm not sure what you mean by this but it's not exactly true.


 7:51 pm on Nov 3, 2009 (gmt 0)

The requirements are the same whether you are level 4 or level 1.

The cost of compliance for a medium sized merchant that I know with sales in the $100m range was $72k. The cost of compliance for a level 1 PSP that I work closely with has been around $400k plus around $100k per annum thereafter.

So I doubt very much that if your company was picked over in detail you would turn out to be compliant. To give an example of compliance, you can't have sub-contracted cleaners in a building housing servers with card details on them unless they are supervised. So either the cleaners have to come in during the day or you have to directly employ them. When I visit the level 1 compliant company that I work with, not only am I signed in and accompanied at every point, they come with me to the toilet and wait outside.

I agree that the banks aren't likely to enforce this sort of stuff on small merchants, but officially you are supposed to comply with it. The big problem will be if there is any sort of proven breach. The official position is that you can be fined $25 PER CARD that is compromised, plus you will be a level 1 merchant following the breach. That's why it would put most of us out of business.

I know that you can get scans etc, and probably it will be OK. But I don't want to walk around with a target on my chest and I would rather be safe. We've had hackers explicitly targeting servers where we have historically stored card details. It isn't just random anymore.

Personally and knowing what I do, I don't like ever entering my card details straight into a merchant site, and I suspect that feeling will grow on the public over time.


 2:19 pm on Nov 4, 2009 (gmt 0)

"The requirements are the same whether you are level 4 or level 1."

That is flat out wrong. For example, level 1 requires an onsite security audit, level 4 does not. There are other marked differences as well.

"The official position is that you can be fined $25 PER CARD that is compromised, plus you will be a level 1 merchant following the breach."

That is flat out wrong. First, if you have a breach you "may be escalated to a higher level". As for fines, Visa can fine you up to $500k per incident if you were not certified compliant.

You are confusing the word "compliant". For my level, I am compliant and it was a long drawn out process. At my level they don't "pick me over in detail". Compliant for level 1 is far different that level 4 and everything in between.

"We've had hackers explicitly targeting servers where we have historically stored card details"

Well to quote from my high school days "duh". Don't store cc details.

Dont get me wrong, I like your position. I think you should think outside the box and be as diligent as is practical. However, I think your stance of lumping all merchants into the same bucket would be as damaging as a breach. If level 4 merchants felt they need to comply to the same level as level 1 then many would simply close up.


 4:16 am on Nov 6, 2009 (gmt 0)

Another gimmick from the banks and card processors that care so deeply for us merchants...


 5:50 pm on Nov 6, 2009 (gmt 0)

Yes, you must comply with PCI.

But, it is a mistake to think that simply complying with PCI keeps you safe. Many security breaches occur from inhouse fraud such as disgruntled employees, unethical outside vendors and lax security measures (for instance, ridulous things such as not even changing the administrative password from "password")

World-wide fraud rings are highly sophisticated organized criminals who have the money and technology to take advantage of the slightest crack in security protections.

This 31 message thread spans 2 pages: 31 ( [1] 2 > >
Global Options:
 top home search open messages active posts  

Home / Forums Index / WebmasterWorld / Ecommerce
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved