Kryptronic Software Support Forum

Well, as you said, if customers aren't complaining then they're likely seeing order confirmation pages.  It would be good to run file-based debugging for a day and see if you can catch anything.  My first look would be a mail server issue, although the save happens before mails go out.  It could be an issue with an OrderMan::init script (custom).  It could be a PHP/MySQL issue: MySQL/MariaDB are touchy with errors on PHP8+ and our version 9.4 is set up to handle this better than any previous versions.  Since we just released 9.4, and that had a bunch of PHP8 updates in it, even if you're not running PHP8 yet, I'd recommend upgrading and see if this issue goes away.  If not, I'd be happy to work with you further to identify and correct whatever is going on.

Thank you for this.  I adjusted your post to remove a bunch of debug lines with store data in them.  I'm seeing an issue here:

CORE_Session::sessupdate: BULKNOUPDATES session update: Array ( [email]=> ) 

CORE_Error::error: Fatal error encountered: Cannot use object of type COREerror as array

I'm looking into it.

Thanks for the alert - confirming you're running 9.4 and it's an issue on that version.

Hi Nick.
Not sure if the Fatal Error is relevant to my problem as I think I may have found the cause.

If you recall, we previously had an issue with a sagepay payment error due to duplicate order numbers not being allowed. In olpform.php we added some logic so checkoutron was run if checkout page was hit again, so a new order number was issued. This resolved the sagepay duplicate transaction issue.

It seems, on rare occassions, a new order number is still raised when users are directed back to site after successful payment, even though they shouldn't get a new order number. This updates the core_session.ecom.cosess with the new order number, and $process_order in ECOM_OrderMan is 0 as $cosess['order_number'] doesn't match the $order['order']['id']. Orderprocess function ends as it thinks the order has already been processed.

I'm trying to create a work around as don't won't to remove the original logic.

a bit more info....
In olpform.php you have this code

    
$js_windowload  = 'jQuery(\'#PAYMENT\').submit(function(){';
$js_windowload .= 'if (window.history && window.history.pushState) {window.history.pushState(\'forward\', null, \'' . $this->link_namespace('ecom','checkoutron') . '\');}';
$js_windowload .= '});';

However, I changed this code a long time ago to

$js_docready = 'jQuery(\'#PAYMENT--SUBMIT\').click(function(){';
$js_docready .= 'if (window.history && window.history.pushState) {setTimeout(function() {ajaxExec({\'primary\': \'ContentWithTitle\', \'callback\': \'ajaxExecResult\',\'app\': \'ecom\',\'ns\': \'checkoutron\'});}, 1500);}';
$js_docready .= '});';

Today I changed back to your version of the code to see if I still have the error we are discussing - I don't appear to as no issues for last 36 hours with orders not being initiated.

However, your code doesn't do what I need it to do - refresh the order number if user clicks back button from sagepay and changes the total amount.
Sagepay won't allow a transaction with the same order number but a different total amount. It just directs user to a generic Form Failed page with no information or error code.

Using your code I know I have missed 3 sales today as sagepay lists the invalid transactions and the errors:
4002 : An active transaction with this VendorTxCode has been found but the Amount is different.
These 3 customers haven't been able to resolve the issue and didn't place any orders.

I think the invalid sagepay issue is always caused when user goes to sagepay and then remembers the loyalty points so returns to my site. They click the loyalty point box and total amount changes. Sagepay now has same order number but different total amount which results in the invalid error.

Using my code, I do not get the invalid error as order number is refreshed every time the user backs out of sagepay, but I do get the orders not being processed error due to order number being refreshed incorrectly after successful payment.

For now I think I stick with catching the orders that aren't being processed as that is better than losing the orders altogether.

Can you think of any improvement to the order number refresh code I could try.

Last edited by zanart (08-04-2025 13:34:19)