phi148 Posted October 16, 2016 Share Posted October 16, 2016 I noticed just recently I was getting these errors: *** MD5 Hash Does Not Match ****** Order Total Does Not Match Transaction Total *** Payments still go through. I started looking into the order total problem and using print statements I found out that this was failing: if ( $response['x_amount'] != $this->format_raw($order->info['total']) ) { $status[] = '*** Order Total Does Not Match Transaction Total ***'; } The "format_raw" function is always returning 0.00. Even though I have a valid value in $order->info['total'] Any clue how this would happen? // format prices without currency formatting function format_raw($number, $currency_code = '', $currency_value = '') { global $currencies, $currency; if (empty($currency_code) || !$this->is_set($currency_code)) { $currency_code = $currency; } if (empty($currency_value) || !is_numeric($currency_value)) { $currency_value = $currencies->currencies[$currency_code]['value']; } return number_format(tep_round($number * $currency_value, $currencies->currencies[$currency_code]['decimal_places']), $currencies->currencies[$currency_code]['decimal_places'], '.', ''); } Quote Link to comment Share on other sites More sharing options...
phi148 Posted October 17, 2016 Author Share Posted October 17, 2016 Ok, so I fixed this, but I have no idea how or why it just happened. I found out the $order->info['total'] contained a dollar sign $. This character bombed during the tep_round call. So I did a simple string replace to fix it like so: // format prices without currency formatting function format_raw($number, $currency_code = '', $currency_value = '') { global $currencies, $currency; if (empty($currency_code) || !$this->is_set($currency_code)) { $currency_code = $currency; } if (empty($currency_value) || !is_numeric($currency_value)) { $currency_value = $currencies->currencies[$currency_code]['value']; } $number = str_replace('$', '', $number); return number_format(tep_round($number * $currency_value, $currencies->currencies[$currency_code]['decimal_places']), $currencies->currencies[$currency_code]['decimal_places'], '.', ''); } How in the world did this just pop up... hmmm Quote Link to comment Share on other sites More sharing options...
♥John W Posted October 17, 2016 Share Posted October 17, 2016 Where are these errors showing up? Meaning, your A.net emails or on your order confirmation page? Quote I'm not really a dog. Link to comment Share on other sites More sharing options...
phi148 Posted October 17, 2016 Author Share Posted October 17, 2016 (edited) Where are these errors showing up? Meaning, your A.net emails or on your order confirmation page? These show up on the order status in admin. Anytime a customer places an order, you can view the details of the authorize.net transaction in the admin area of the store, in the order details. These errors are not displayed to the customer, they act as a warning only. They payments still go through. I just don't understand why all of a sudden I have to remove a dollar sign character, when for the past 2 years I never had a problem. I must of changed something, somewhere. Edited October 17, 2016 by phi148 Quote Link to comment Share on other sites More sharing options...
♥John W Posted October 27, 2016 Share Posted October 27, 2016 (edited) Sorry for the late response. I modified my module and i don't use that in the stock way. I also modified mine to output the actual A.net error like you see in the debug emails that are generated when there's a problem. So, the user sees the real error. I find it more helpful. But, I don't see any problems like that anywhere. Edited October 27, 2016 by John W Quote I'm not really a dog. Link to comment Share on other sites More sharing options...
phi148 Posted February 3, 2018 Author Share Posted February 3, 2018 (edited) So in looking at this more, I think I know why this is happening. Any order over 999.99, I believe has a "comma" in the amount like this: $1,000 I think that comma is screwing up the calculations here. I think the $order->info['total'] is containing a comma, therefore the MD5 hash doesn't match and I also get the order total not matching if ( tep_not_null(MODULE_PAYMENT_AUTHORIZENET_CC_AIM_MD5_HASH) ) { if ( strtoupper($response['x_MD5_Hash']) == strtoupper(md5(MODULE_PAYMENT_AUTHORIZENET_CC_AIM_MD5_HASH . MODULE_PAYMENT_AUTHORIZENET_CC_AIM_LOGIN_ID . $response['x_trans_id'] . $this->format_raw($order->info['total']))) ) { $status[] = 'MD5 Hash: Match'; } else { $status[] = '*** MD5 Hash Does Not Match ***'; } } if ( $response['x_amount'] != $this->format_raw($order->info['total']) ) { $status[] = '*** Order Total Does Not Match Transaction Total ***'; } the "format_raw" function only removes the "$" but not the comma. Edited February 3, 2018 by phi148 Quote Link to comment Share on other sites More sharing options...
phi148 Posted February 3, 2018 Author Share Posted February 3, 2018 (edited) Actually, I think it should be removing the comma... I believe the code below should indeed do that. So now I'm really confused on how this is only happening for totals over 999.99 .... hmm. It still must be the comma somehow. Looks like I need to add some print statements to know for sure. // format prices without currency formatting function format_raw($number, $currency_code = '', $currency_value = '') { global $currencies, $currency; if (empty($currency_code) || !$this->is_set($currency_code)) { $currency_code = $currency; } if (empty($currency_value) || !is_numeric($currency_value)) { $currency_value = $currencies->currencies[$currency_code]['value']; } $number = str_replace('$', '', $number); return number_format(tep_round($number * $currency_value, $currencies->currencies[$currency_code]['decimal_places']), $currencies->currencies[$currency_code]['decimal_places'], '.', ''); } Edited February 3, 2018 by phi148 Quote Link to comment Share on other sites More sharing options...
phi148 Posted February 4, 2018 Author Share Posted February 4, 2018 I'm just going to put this in as a temp fix $number = str_replace(',', '', $number); I think the tep_round is bombing again because of the comma in the format_raw Hopefully this helps someone else should it ever happen Quote Link to comment Share on other sites More sharing options...
♥Dan Cole Posted February 4, 2018 Share Posted February 4, 2018 @phi148 Bill is this happening with all orders over $1,000. I don't remember ever noticing any warnings like your seeing but I'll take a quick look. I assume you're seeing the messages in the comments area for the order status? Dan Quote Need help? See this thread and provide the information requested. Is your version of osC up to date? You'll find the latest osC community version (CE Phoenix) here. Link to comment Share on other sites More sharing options...
phi148 Posted February 4, 2018 Author Share Posted February 4, 2018 Just now, Dan Cole said: @phi148 Bill is this happening with all orders over $1,000. I don't remember ever noticing any warnings like your seeing but I'll take a quick look. I assume you're seeing the messages in the comments area for the order status? Dan Yes, all orders over 999.99. I had to remove the "$" and the "," symbols and now all is working. However, I think the root cause is higher up in the admin/includes/classes/order.php I don't think the $order->info['total'] Should have ever been populated with anything other than numbers, but I imagine one of my various contributions inadvertently changed that. Bottom line, if you are not seeing the problem, then no need to worry about this thread :) Quote Link to comment Share on other sites More sharing options...
♥Dan Cole Posted February 4, 2018 Share Posted February 4, 2018 12 minutes ago, phi148 said: Should have ever been populated with anything other than numbers, but I imagine one of my various contributions inadvertently changed that. That is probably a good bet....I checked a half a dozen orders over $1000.00 and there were no warning messages like those that you described so I don't think the problem is with the AIM module. Dan Quote Need help? See this thread and provide the information requested. Is your version of osC up to date? You'll find the latest osC community version (CE Phoenix) here. Link to comment Share on other sites More sharing options...
phi148 Posted February 4, 2018 Author Share Posted February 4, 2018 Just now, Dan Cole said: That is probably a good bet....I checked a half a dozen orders over $1000.00 and there were no warning messages like those that you described so I don't think the problem is with the AIM module. Dan Good to hear, thanks for checking! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.