2.1.0 Before New Year's Eve!

Yeah, you shouldn’t even look here, but I think, with all those small glitches we’ve got with 2.0.9, CS guys will surprise us before we get a year older. I hope so :wink:

[quote name=‘Noman’]Yeah, you shouldn’t even look here, but I think, with all those small glitches we’ve got with 2.0.9, CS guys will surprise us before we get a year older. I hope so ;)[/QUOTE]

Well, I am hoping it is 2.0.10 - that is, a bug fix release with no new features.



Bob

I think they should change to 2.0.9.1 for bug fix release. Not for 2.0.10

Look at the bug tracker. What a Joke. I;ve been using this software for years and giving up. As far as I’m concerned 1.3.4 was the best they had and conversion rates were at their best, Simple and fast, That’s all customers want. I’ve hosted with the top dedicated server companies in the world for over 15 years. This is bloated, sluggish, customer confusing, buggy software. I’m moving on.

Hi Keith, can you give some alternatives as to which software are you moving on too? :cool: Just for reference purposes… at least a backup solution for my case. Better than have the bridges burnt to point of no return.



What really disappoint me was that after the big hoo-ha of a terrible v2.0.7 upgrade version, and where their clients (aka us) have gave repeated advice to TEST TEST TEST their upgrades before releasing it to the innocent public, I thought they would have listen to that advice. I had hopes that they were taking the time to thoroughly test v2.0.9 upgrade prior to releasing it, that is why I was SO patiently waiting for the release which promised to fix loads of bugs as stated in their bug tracker (aka replies that said "Fixed in v2.0.9).



But with the release of v2.0.9 upgrade, the STARK POINTED proof that they did not even attempted to test the upgrade at all, left me totally bewildered and frustrated. And as a ecommerce software provider, the credit card storage option (which cannot be turned off) is an unforgiving mistake. Even if the programmers did not know any better, the person vetting the release, or the business personnel should know and advise better. It is totally against PCI compliance.

Nodame,

I have seen your bug reports regarding PCI compliance and the storage of credit cards.

I and others do offline credit card processing. I have to download the info and then import into Quickbooks. Then delete CC info. To do this, there has to be some sort of storage of information or I would not be able to process the order.

Bob

[quote name=‘pbannette’]Nodame,

I have seen your bug reports regarding PCI compliance and the storage of credit cards.

I and others do offline credit card processing. I have to download the info and then import into Quickbooks. Then delete CC info. To do this, there has to be some sort of storage of information or I would not be able to process the order.

Bob[/QUOTE]



True, that it can be useful for some store owners. But there seems to be no options to disable it, and it should at least ensure that storage is only possible if user profiles are only running on SSL authenticated pages, else it is very prone to possible misuse.



Just to note and highlight, I have no problems/issues with the current (v2.0.8 and prior) method of storing then deleting cc info that are attached to orders after you’ve processed the info. It is fine with me if store owners collect CC info as a form of payment method WHEN a customer places an order. Of course, the owner should ensure that they passed the PCI compliance test, etc etc. And then proceed to delete the CC info once the order have been successfully processed and completed.



But now users are able to store their CC info on their profiles pages, regardless if they have placed an order with a credit card based payment method, including their CVV2 information.



Maybe I have not look closely enough, but I am not sure where can I delete the credit card information user store in their profile (not associated with orders). And also if everytime a user decided to save new cc information in their profile, I have to go in and delete it, it will be troublesome right?



Honestly, I’m do not have my own credit card merchant account, am currently using worldpay and paypal (both 3rd party), where customers can get directed to the very secure payment pages to enter their cc informaiton. And I certainly do not wished to have customers storing their CC info on my site (when I have no use for that), and then have future possible identity fraud, hacking issues to deal with later on.

I really hope not. 2.0.9 seems like a complete failure compared to other releases. I really hope they start to take their time and get rid of most bugs. I hope the next release doesn’t come with any new features.



I think they need to release a stable version before improving features. After reading every-ones experience from 2.0.8 to 2.0.9 I wont be updating soon. I’m going to hire someone to manually fix the handful of bugs in 2.0.8 and stick with it instead of moving to 2.0.9 with a soup full of bugs.

I think you control storing CC info under order statuses. “i think”, take a look at that and see if there is a spot to turn off storing CC’s.

I’m going to dress up like a gigantic bug for new years and run around around the neighborhood waving sparklers…

[quote name=‘ETInteractive’]I think you control storing CC info under order statuses. “i think”, take a look at that and see if there is a spot to turn off storing CC’s.[/QUOTE]



In v2.0.9, it is no longer so.

Customers can add cc details at their profile, and not tied to orders.



screenshot from demo store





as shown in the image below:





If you noticed, the cvv2 information are being stored.

[quote name=‘snorocket’]I’m going to dress up like a gigantic bug for new years and run around around the neighborhood waving sparklers…[/QUOTE]



haha :slight_smile:

just when you thought halloween is over and you can store that costume into storage…

Who ever thought this new “store credit” card idea was a good idea needs their head examined. If you store ANY credit card data you MUST be PCI compliant. That means dedicated firewall, separate database and web server, Intrusion detection, a web hot who who has a PCI compliant facility and a host of other items. If you are on a shared host, VPS, or a cloud you are can not be PCI compliant as that environment is not condusive to that level of security. Now assuming you are fully PCI compliant this feature just wiped that out as you CAN NOT UNDER ANY CIRCUMSTANCES store the CVV number.





PCI DSS Requirement:



3.2.2 Do not store the cardverification

code or value (threedigit

or four-digit number printed on

the front or back of a payment

card) used to verify card-notpresent

transactions.



On top of this when the customer goes to the cart this data is made visible in the CC form fields. That means that anyone who can hack a user account or your admin account can access that data for all of your customers. The fact this data is even visible at all in the CC fields means it’s not encrypted in the database. MD5 encryption is a one way encryption. That means you can only verify a hash on the encryption not read the original encrypted data.



Shame on you CSC, this is a SERIOUS security breach you have introduced to everyone’s cart. It’s also worth noting that if ever you were to have your security compromised you could lose your merchant account and be fined in the thousands or hundreds of thousands per month. PCI compliance is MANDATORY for everyone who takes credit card data, regardless of whether the credit card is take on a CC processors site or on your own. The requirements changes based on your set up, but even your credit card holders name, address needs to be protected per PCI compliance rules.

[quote name=‘snorocket’]I’m going to dress up like a gigantic bug for new years and run around around the neighborhood waving sparklers…[/QUOTE]



Why wait for New Years. I’d send you a Pay Pal payment to see this…like now!

good morning :smiley:

Good Morning love :slight_smile:

Dead on about PCI compliance. I do believe that the reason they inserted the option to save credit card information MAY be connected to the recurring billing/subscription module - however I don’t think this data should be stored on the server really.



It’s an unnecessary risk.

Regardless, there needs to be a switch to turn this on or off via the admin. And yes, an actual switch, not hacking code

[quote name=‘jagorny’]Dead on about PCI compliance. I do believe that the reason they inserted the option to save credit card information MAY be connected to the recurring billing/subscription module - however I don’t think this data should be stored on the server really.[/QUOTE]

Yep, looks like they wanted a universal way to handle recurring billing rather than reworking the code to interface with each payment processor (since not all offer recurring billing). They need to spend the time to incorporate ARB for those processors who offer it (e.g., Authorize.net who uses a seed number from the original transaction thus staying PCI-compiant).



Bob

[quote name=‘timst’]Regardless, there needs to be a switch to turn this on or off via the admin. And yes, an actual switch, not hacking code[/QUOTE]

I wonder how Amazon stays PCI-compliant when they store credit card info? I guess their resources allow them to create solutions unavailable to us mere mortals.



Bob