Indeed, PCI compliance is for everyone who wants a merchant account (at least in the US).  But quit the scare tactics (and ASPDNSF has been using them for years).   I have gotten a merchant account recently and went through the compliance questionnaire for the ML/DNN product.  I also went to the PCI site myself to figure out what was necessary to comply, even though ML/DNN "couldn't" get PA/DSS.   Be real, from a merchant perspective, the rules aren't more than common sense.  Let Authorize.net store the credit card data and you're fine (yes, you need SSL etc).  Authorize.net isn't a "boomerang" so it meets your criteria.

Next, I really believe that if you had also taken a common sense approach to the PA/DSS issue, you could have gotten around that without explicit cooperation from DNN corp!   Stuff like "Don't use default id/passwords on the site".  Come on, any hacker knows the default host/portal ids (hope you do too).  A high schooler also knows how to query the database for them and remove them!   During installation you check...does the site still have the default host/portal ids?   If so, scare the user, tell them they can't be PCI compliant with that and that the install will stop unless you agree to remove them.   Then, SQL query poof!  Not difficult!   If you felt that more security needed to occur on the Admin site, you could have had a second log in for that...it's your app, you could have whatever encryption you wanted there.  Customers shouldn't have needed this level of security so it wouldn't have affected core DNN.   Security on 'private data" (name/address etc)?   We think you could have managed that through an extra routine, but that doesn't seem required by PA/DSS...just the PAN and other credit card info - which, by the way, I don't store in the database!

Why, in 4 years you guys couldn't figure this stuff out, I don't know.   But I wish you had thought about it before you dragged your customers through the mud.

I was at the round-table meeting at the end of the OpenForce conference this year, when this very question came up, directed towards the DNN core team.   Joe Brinkman spoke for a while on the topic, and while I'm no expert in this area, his responses seemed entirely reasonable to me.  I don't recall the exact details but I think the main theme was : we can't get compliance because the base DNN install doesn't do the things needed.  In other words, you can't get certfication for a platform which doesn't even do the thing certification is for.  Or, trying again, DNN isnt' an e-commerce platform out of the box, so you can't certify it as one.  In addition, since many DNN installs contain a variety of installed code, each certification has to be done on a case by case basis.

Happy to be corrected if I'm wrong on this one.  It was a while ago and at the end of a conference on a topic I'm only tangenitally interested in.

To me it seems as though the certification issue is being used as a good reason for exiting the DNN ASPDNSF product range.  It hasn't been the happiest of marriages (I know I've spent countless hours helping people get their sites going) and I suspect both camps are happy to go their separate ways.

It would also seem reasonable to me that a checklist-style procedure could be developed for obtaining certification regardless of the platform.   If that means deleting the standard host/admin accounts, then I don't see why this can't be procedurised. But again, I'm talking out of my knowledge depth so perhaps someone more qualified than I shoudl contribute on this point.