I had a look at wikipedia about this - doesn't this relate to how you store people's credit cards on your server - sorry if I seem very ignorant about this - but I am interested in knowing more.

http://en.wikipedia.org/wiki/PCI_DSS

I would have thought this would relate to how people store customer credit cards on their server - but if you adopt the policy of many people, and NOT store credit cards on the server, but use a third party gateway to handle the payments using the correct SSL certificate would cover this.

If you did not store anyone's credit card details and you are using a third party api and gateway, doing the transactio on their 'compliant' servers, then I can't seem to work out the logic here. Perhaps I am missing something, but as far as my thinking is, and the relationship I have with my clients who sell online, we don't and have never stored people's credit cards on our infrastructure, but chosen to use third party providers, so why would that affect them?

And I don't understand how it can be assumed that DNN itself should invest in beign 'certified' when it provides the framework for the community to build on.  I could understand however, that someone who needs this as part of them doing business may need to invest in getting this done.

Do you have any more reading on this matter?

Nina

As always, Nina's posts (apparently rare these days?) are right on the money. No, DNN does not have to be certified by any means. The store module they're using, maybe (if at all). If it's using a payment gateway, which most stores do, there's no problem. Just don't store credit card info, security codes, etc. If you have to, encrypt them or better yet, download them to a protected, not publicly accessible computer. 

I have had an online storefront since 1995. I'm always amazed at the lengths the credit card companies go to, to "insure" secure transactions (NOT!). PCI DSS is just another measure of vague guidelines and "multifaceted security standards" as they call it, that they use to CTP (cover their posteriors). Basically, PCI DSS is their shield. In case your data gets compromised, they'll flash their PCI DSS guidelines, hit your over the head with them and say it's all your fault.

On the other hand, many years ago (about 10), out of 3 fraudulent transactions that got by my system's security precautions (in 15 years!!!!), I managed to get complete purchaser information from one particular "bozo". I had the IP address and significant personally identifying information, down to a his IP address (easy), his computer's network card MAC address (quite a bit harder) and a reliable, physical address. I immediately contacted the credit card owner's card issuing bank.  Imagine my surprise when they didn't give a s**t. They didn't even want the information I had. They could have easily snagged the crook, but they really, really didn't want to. As a merchant, I am painfully aware that anytime there is a problem with a transaction, they'll simply charge back to your account (i.e., take the money back!) and it's ALWAYS your loss. 

The credit card companies really have no incentive to create an environment for safe and secure transactions. While technically possible to do so, 16 digits, an expiration date plus a 3/4 digit security code really don't cut it anymore for online transactions. PCI DSS  to the rescue? You have got to be kidding!!! It's a lot easier for them to come up with fairly meaningless guidelines than actually implement a simple challenge/response system that could easily verify online transactions and eliminate 99% of the problems in the first place.

I apologize for hijacking this thread to (mostly) vent.