Latest News: (loading..)


  • Content count

  • Joined

  • Last visited

About phi148

  • Birthday 01/01/2006

Profile Information

Recent Profile Visitors

10,205 profile views
  • Cary

  1. Thanks everyone much appreciated for all the info and feedback!
  2. Hi I received an email today from that stated the following: Dear Authorize.Net Partner: As you may be aware, new PCI DSS requirements state that all payment systems must disable early TLS by 2018. In preparation for this requirement, Authorize.Net plans to disable TLS 1.0 and TLS 1.1 on the following dates: Sandbox: April 30, 2017 Production: September 18, 2017 We are disabling the sandbox in advance of production to allow you and your merchants time to test your solutions and ensure you are no longer using TLS 1.0 or 1.1. Please check the code for your solutions and systems to confirm that they can default to TLS 1.2 for your API connections. You can review our API Best Practices for details about TLS 1.2 platform support and other integration suggestions. Thank you for your attention to this matter and for being an Authorize.Net developer. Sincerely, Authorize.Net Does anyone know if this AIM package is TLS 1.2 compliant ?? Thanks!
  3. These show up on the order status in admin. Anytime a customer places an order, you can view the details of the 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.
  4. 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
  5. Thanks John! That appears to do the trick! 60-90 days is a good grace period to have when using the AIM method. The CIM method of does allow ease of use for a returning customer as their card is saved for them. (And helps us by not having to ask them for it again if a phone order). Each have their pro's & con's :)
  6. Unfortunately COD is not available. It is just the nature of LTL freight. I agree that adding a notice so it is clear is the way to go. Thanks!
  7. 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'], '.', ''); }
  8. Hi John, I guess i'm a little confused. I don't see anywhere in my admin area where I can RECHARGE the customer again within 60 or 90 days. I only see an option to refund the customer. I don't use Fedex or UPS. My products are too large. They ship via LTL freight carriers... and I only find out they used liftgate when I get the bill. Sometimes the delivery driver themselves encourage they use it! Argg!
  9. I live in the United States. I offer many shipping options at the point of sale. The customers simply do not purchase it most of the time. Then, at time of delivery, they end up using a service that they did not purchase, like "liftgate".... and then I get charged for it.
  10. Very good advice. I like your suggestion regarding the check box / similar to a "must agree to terms" check box at checkout. Because you are correct, not many people read the fine print!
  11. Hi All, We deal largely in selling large items that are too big for Fedex or UPS. They require a LTL freight carrier. That being said, sometimes our customers choose to add delivery services (Like liftgate) AFTER the initial sale. Unfortunately, when a customer adds a delivery service, my company gets charged for it. Going after the customer to get their credit card information again and attempt to charge them is usually a huge problem. Since OSCommerce does not store credit card information, I don't have a way to "recharge" them if they add any additional services after the initial sale. I think I found a way around that, as offers a "CIM" service where they store credit card information on their system. This would allow me to RECHARGE a customer should they add any services. That being said, is it LEGAL to do that? I would have in my terms & conditions that we would charge them if they add additional services... but I wasn't sure if that really is a legal thing to do. Any thoughts? Thanks!
  12. I see the SIM, AIM and DPM but no CIM modules seem to be available?
  13. Something with Mod Security was the issue. I finally threw in the towel, got rid of a shared hosting and now use a VPS. Problem solved, plus a faster website to boot. :) Thanks all for the feedback!
  14. Dang it... I was incorrect. I didn't see the problem yesterday because I wasn't logged in. Happened again today. I'm checking to see if my host re-enabled MOD_SECURITY. If they didn't, then that is no longer the issue.
  15. Yes sir, I verified the configure.php was correct. I *think* the problem went away yesterday after disabling MOD_SECURITY and I removed all my CRON jobs. Point of note, I did not think my CRON jobs were the problem, as none of them run on a 25 hour schedule. However, I disabled these per the hosts request. I have added back my CRON jobs ... so now, the only thing disabled is MOD_SECURITY. Will monitor today to see if it happens. I'll keep you all posted and can't thank you enough for the feedback!