I agree that miscommunication and ego contributed to this.  However, fundamentally, ASPDNSF wasn't willing to invest the time to understand DNN.   Their original product "functioned" under ASP.net, but never took advantage of it.  As a result, it was a total bear to update.  They even said that they had their own "special coding style".   Indeed...it was special!   Take the special sauce and then attempt to force it to conform to a platform that you don't even understand and it's a recipe for disaster.   Add in the desire to use offshore programmers (one source of the blame for all the delays and bugs).   I really think the reason they couldn't support the product well is because they blamed other parties, rather than trying to understand how to make their product NOT interact poorly with theirs.

Plus, some of these "bugs" were not just small little fixes.  They were signs of poor design and lack of understanding of DNN!   I think people can understand "little bugs".   I tried to forgive for misspelled appconfig names.   I tried to forgive the poor rounding.  But trying to do a form submit just isn't going to work in DNN and a web.request won't work for Paypal.  Anyone who has attempted to do ecommerce should know this!  

I think they got in over their head and should have done a better job of managing the situation and tried to be fair to their customers who spent LOTS of money on a product that 4 years later will only work with custom coding fixes.   That doesn't even include the issues such as registration that "technically" work, but are so "unfriendly" that customers will run away. 

I don't think a money back guarantee is going to materialize anytime soon even though it often feels warranted. A class action suit certainly does sound appealing. And the ASPDNSF has been eerily siolent on the issue, going so far as to now remove a forum thread on the whole situation.

I don't see how ASPDNSF could dispute the general consensus that they were way outside their comfort zone on this one, and it didn't help that because they had limited understanding of the integration chanllenges, weren't able to adequately offshore the coding. I saw some things in the code 3 years into it that I couldn't believe I was seeing.

And to blame it on compliance is a thin argument, especially because it was such a weak integration even up until the end.

I also don't think that it's worth trying to salvage an ML/DNN installation that's trying to do commerce because of the total disconnect on the whole registration process and customer (user) profiling. Last I saw, there were at least 4 different tables involved in storing customer information depending on whether they were a one-off customer, recurring order customer, drop ship destination, or otherwise. And quite often, the information was duplicated across those tables except for slight variances because some of the input scrubbing was wildly inconsistent. ASPDNSF as a catalog (no eCommerce) works OK though.

Honestly, I'd love to explicitly vent on this whole thing because I'm very angry at the whole situation, but worry that my hope of salvaging the situation by getting trade-in licenses to the ML/64 version for all of my useless ML/DNN licenses would be in jeopardy. At the least, I think it's completely reasonable to expect ASPDNSF to grant trade-in licenses to any equivalent, supported, actively developed product in the lineup.

And as Bruce mentioned, I was the one who queried the DNN Panel at OpenForce about the compliance issue. I had a bad feeling at the time of what "wasn't happening" with the whole "he said she said" forum arguments surrounding the issue. At the same time, I suggested that DNN pick up the ball and implement a commerce API that aftermarket vendors could utilize for transactions. Remember when DNN 3 had all sorts of payment gateway choices in the site settings dropdown? Not that any of them worked, but at one time somebody was thinking about it.

Anyway, I'm glad this thread is staying alive, at least so that all of us commerce orphans have a support group!