Welcome to WebmasterWorld Guest from 18.104.22.168
Forum Moderators: buckworks
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?
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?
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.
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]
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.
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?
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.
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.
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.
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.
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.
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]
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.
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.
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.
why not just load the third party site into an iframe of your own site
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".
Merchant level 4:
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
Recommended annual PCI Self-Assessment Questionnaire and quarterly network scan
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.
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.
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.
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.
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.
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.
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.