dreamscape Posted February 24, 2004 Share Posted February 24, 2004 This problem exists in all osCommerce version since at least Nov 2002. There is a pretty big logic error in checkout_process.php. We discovered this the other day in our osCommerce stores (circa MS1) and I downloaded both osCommerce MS2 and the CVS, both of which also have the error. The problem is encountered with payment modules who use checkout_process.php as the page they submit their form to. This is mostly used for making connections to credit card processors in the background via curl, etc (authorize.net AIM/ADC, ECHO Inc, etc). In these types of payment modules where the connection is made in the background using checkout_process.php as the payment's form URL, the order information is usually sent to the processor in the payment module using the before_process() function. However, there is a logical flaw in checkout_process that prevents any 3rd party order_total modules such as discount coupons, bulk discounts, etc from being sent to the credit card processor. The discount shows on the website to the customer and also shows in the database to the admin, however, is not passed onto the processor and the customer is actually charged the full amount of the order without the discounts. I know osCommerce does not officially support discounts and other 3rd party order_total modules; however, that is completely irrelevant as the error is in checkout_process's logic. Now, here is the simple logical error. When using direct connection methods to payment processors, the before_process() function can be seen as the "process payment" function, whereas in payment modules that use a 3rd party's form URL, the process_button() function can be seen as the "process payment" function. With direct connection type payment modules, the basic logical layout of checkout_process.php can be viewed as: -> create new order -> process payment -> process order_total modules -> insert order into dB The middle 2 are backwards. The order_total modules should be processed before the payment is. When using 3rd party form URLs this is not a problem, and maybe why it has gone so long unreported and unfixed, because in the case of 3rd party form URLs the payment is processed before it gets to checkout_process.php, so it appears correct, though fundamentally still incorrect. The processing of the order_total modules should come before the processing of the payment. That I know of, this logical error effects the authorize.net AIM/ADC module and any other current or future payment modules using direct connection methods. ECHO is technically not effected, but only because the ECHO module passes the correct $order->['total'] value already processed by the order_total modules from checkout_confirmation.php to checkout_process.php for use in the before_process() function to process the payment. However, not all direct connection method modules do this (auth.net AIM/ADC does not) and nor is it really necessary to repost all of the order and order_total data either, since with direct connection payment modules it goes straight to checkout_process for processing, instead of going to a 3rd party form URL and then checkout_process. For those using direct connection method payment modules, here is a fix. In checkout_process.php, change the following lines: ?require(DIR_WS_CLASSES . 'order.php'); ?$order = new order; // load the before_process function from the payment modules ?$payment_modules->before_process(); ?require(DIR_WS_CLASSES . 'order_total.php'); ?$order_total_modules = new order_total; ?$order_totals = $order_total_modules->process(); to this: ?require(DIR_WS_CLASSES . 'order.php'); ?$order = new order; ?require(DIR_WS_CLASSES . 'order_total.php'); ?$order_total_modules = new order_total; ?$order_totals = $order_total_modules->process(); // load the before_process function from the payment modules ?$payment_modules->before_process(); For those using the auth.net AIM/ADC module you will also need to move the call to authorize_direct.php to after the order_total modules are processed. This has been submitted to the bug reporter and will hopefully be fixed in CVS sometime soon, but since it affects all osCommerce versions since at least November 2002, I figured I would post it here as well with a fix for those of us using direct connection payment modules (auth.net AIM) and 3rd party order_total modules. The only thing necessary for evil to flourish is for good men to do nothing - Edmund Burke Link to comment Share on other sites More sharing options...
dreamscape Posted March 1, 2004 Author Share Posted March 1, 2004 well so I take it from the general lack of reply from any of the osCommerce community (including the dev team, as this still remains unfixed), that nobody really cares about this error?? ok, thats cool I guess... if you're into fraud. The only thing necessary for evil to flourish is for good men to do nothing - Edmund Burke Link to comment Share on other sites More sharing options...
Mark Evans Posted March 1, 2004 Share Posted March 1, 2004 well so I take it from the general lack of reply from any of the osCommerce community (including the dev team, as this still remains unfixed), that nobody really cares about this error?? ok, thats cool I guess... if you're into fraud. I can't speak for the general community but I can tell you that this issue is being looked into by the dev team. The lack of reply is most likely due to the recent developers meeting which has kept many of us away from our computers :) Mark Evans osCommerce Monkey & Lead Guitarist for "Sparky + the Monkeys" (Album on sale in all good record shops) --------------------------------------- Software is like sex: It's better when it's free. (Linus Torvalds) Link to comment Share on other sites More sharing options...
Austin519 Posted March 25, 2004 Share Posted March 25, 2004 dreamscape: Good call...and it's correct in Authorize.net Consolidated...and don't feel bad about them replying...I submitted a bug about SMTP mail under win32 about 9 months ago (that kept smtp emails from sending) and it's been marked pending ever since with no updates... Austin519 Link to comment Share on other sites More sharing options...
pete2007 Posted May 2, 2009 Share Posted May 2, 2009 Hi, Would I be able to use this module for a whole catagory, example: I will give 10% discount for any 4 T-Shirts purchased across the catagory? Any help would be most appreciated! Link to comment Share on other sites More sharing options...
erihp44 Posted November 5, 2009 Share Posted November 5, 2009 thank you for this fix, applying this fixed my problem and afterwards my payments module's diagnostic passed this test. thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.