0.01 Cent Orders and 0.01 Cent Subtotals

I have an odd issue that came up these past two week. I had two unusual orders go through. One customer purchased a couple of items from me and the total my PayPal account received was 0.01, but his total was over 50 dollars. Another customer had the same issue today, where I was charged 0.01 for some video downloads totaling over 40 dollars.

I requested from the first customer to pay through PayPal and he did. However I've refunded all three transactions in case of fraud, I don't want any charge-backs. Was the first customer honest or was he using a stolen card?

However, I suspect it might not be fraud. Here is why. The image below shows a customer who ordered tonight. His transaction was successful and his funds went through to PayPal (I was paid). The issue is that the transaction shows a subtotal of 0.01. There are also a few numbers that I don't quite understand and circled in the image. Why so many decimal places? And why are they 000.01 and not 355.00 in context with the others?

Logs: Here is what my log file said is going on...

[17-Sep-2013 03:54:16] PHP Warning: preg_match() [<a href='function.preg-match'>function.preg-match</a>]: Compilation failed: nothing to repeat at offset 48 in /homepages/1/d330079732/htdocs/www.stopmotionstore.com/includes/modules/shipping/usps.php on line 420

and...

[17-Sep-2013 18:34:00] PHP Warning: htmlspecialchars() [<a href='function.htmlspecialchars'>function.htmlspecialchars</a>]: Invalid multibyte sequence in argument in /homepages/1/d330079732/htdocs/www.stopmotionstore.com/admin123/includes/modules/product/collect_info.php on line 401

Does anyone know what might be going on? Is this truly fraud or just a mis-configuration? Maybe in the shipping module? My fear is that I could be making some customers mad who are being honest. At the same time I don't want to get those charge-backs.

The store runs on ZenCart version v1.5.1. I appreciate anyone who can figure out where I've gone wrong.

You should change the name of your admin folder IMMEDIATELY, since you've published it to the world.

Thanks, I just did. Does anyone have any ideas about what could be going on with the 0.01 cent issue and how it might be solved?

Alright, hopefully this clue will be enough to get a response as to what this problem is. While looking at my store I noticed a product listed for $000.01. Then I hit refresh and both items changed to $000.01, and then finally after refreshing again they reverted to the price that I have listed in the admin. Here is a screen shot.

Does anyone have a clue as to why this may happen?

Personally I've never seen that on a stock Zen Cart installation. Was your site upgraded to 1.5.1 from previous version? What plugins (included full version numbers) have been installed? What is different from a stock Zen Cart 1.5.1 installation? Are there any Zen Cart debug logs, php error logs, or server error logs? Is there corruption in the database (or any database communication issues - such as mismatched encoding)?

After 1&1 (my host) updated to the latest version of PHP, that's when this seems to have happened. I also installed the latest USPS update a few weeks ago, but I can't say if this played a part.

Yes, Zencart was updated incrementally for years by a friend of mine who followed all the upgrade instructions carefully. Not that he can't make mistakes of course but he's pretty good at this sort of thing. I did notice when changing the URL of our admin folder (as lat9 suggested above), that the advice on ZenCart to simply change the folder name and URL didn't work for my version (1.5.1). I had to use the advice to change it for older versions of Zen 1.3.x as outlined here http://www.zen-cart.com/content.php?75

There are only two things installed outside of the stock installation and they are just themes. One for mobile use and one for the over-all theme on web based browsers.

Error messages are as follows in our logs:

PHP Parse error: syntax error, unexpected T_STRING in /homepages/1/d330079732/htdocs/www.stopmotionstore.com/includes/languages/english/meta_tags.php on line 17

This one sticks out for some reason, could it be the latest USPS update I installed a few weeks ago?:

[16-Mar-2013 21:24:26 America/New_York] PHP Warning: Creating default object from empty value in /homepages/1/d330079732/htdocs/www.stopmotionstore.com/includes/modules/shipping_estimator.php on line 117

This error popped up frequently only before the last PHP update on our server and disappeared after it. It has a string of code after it that is garbled and very long:

[18-Mar-2013 02:02:00] PHP Fatal error: 1062:Duplicate entry 'zc_6ec65decb95a7741ada473af0fde76e1' for key 'PRIMARY' :: insert into zen_db_cache set cache_entry_name = 'zc_6ec65decb95a7741ada473af0fde76e1',

Another old one that doesn't seem to happen since the PHP update:

[20-Mar-2013 04:32:54] PHP Warning: htmlspecialchars() [<a href='function.htmlspecialchars'>function.htmlspecialchars</a>]: Invalid multibyte sequence in argument in /homepages/1/d330079732/htdocs/www.stopmotionstore.com/includes/functions/functions_general.php on line 74

I can't answer all your questions, but I'll have my friend take a look and see if he can help me answer the rest and get back to you.

My personal sites are hosted by 1&1, too, and I haven't experienced the issue you're describing. That said, a couple of questions/comments:

1. You say your site's been upgraded to v1.5.1. What database collation were you using before the upgrade and what's the current setting in your /YOUR_ADMIN/includes/configure.php and /includes/configure.php for DB_CHARSET? When you look at your database using phpMyAdmin, what collation (i.e. character set) is actually being used in your database?
2. Your store is using utf-8 as the display character set (see either /includes/languages/YOUR_TEMPLATE/english.php or, if that doesn't exist, /includes/languages/english.php for the CHARSET definition). Most likely, your previous store was using one of the iso character set types and your meta_tags.php has a non-utf-8 character in it on line 17.
   While neither of these circumstances gives me a clue regarding your 0.01 cent orders, they are germane relative to the debug log files you're seeing. Your easiest path to correcting these errors depends on what your database current collation is.

Thanks lat9 for your help. I discovered the problem, and I think that you might be able to reproduce it if you do what I did (if you feel the need). When I was updating another site on the server, the latest PHP update broke it. It was a Joomla based page and we had an older version installed that wasn't compatible. So what I did was downgrade temporarily PHP from 5.4 to 5.2 and forgot to set it back to 5.4. After switching back to 5.4 yesterday, the problem was resolved.

Just for added info, I noticed that any items with five digit prices seemed most likely to have the problem. So 159.99 would switch to 000.01, but 49.00 would rarely have this problem when you refreshed pages. I also noticed one item had always switched to 000.01, and it was priced at 159.99. So I created a new test product with the same price in the same category, and it would switch to 000.01 more than other products. If anyone else has the same symptoms - the cure is to make sure PHP is correctly set to 5.4.