OpenCart Community

Hi, can anyone help me with this issue please? (v2.3.0.2)

Just had an order come through via Woldpay and the order cleared in both Worldpay and in the Admin orders area. However, the client emailed asking if the order went through successfully as instead of the success message they got the attached error instead..

"There are an error processing your order. Please contact the shop administrator for help."

The order status in Opencart Admin was correctly set as 'Pending' and there don't appear to be any issues with it, it's only that the wrong message was provided to client. The shop has been running for a while now and no previous order issues such as this one..

I've spoken to Worldpay but they said the order looks fine their end and the issue is somewhere on Opencart side.

Does anyone know why it happened, and how to fix it?

Many Thanks!

Enable the debug mode in your Worldpay admin payment module page. Then, test another transaction. Check the Worldpay logs either from your admin - > systems - > maintenance - > error logs page or from your Worldpay admin payment module page's logs tab afterwards.

Thanks for the reply.

I took your advice and enabled the log file, which gave the following 2 errors on the next order:

PHP Notice: Undefined variable: order_status_id in /public_html/domain/catalog/controller/extension/payment/worldpay.php on line 194
PHP Notice: Undefined variable: order_status_id in /public_html/domain/catalog/controller/extension/payment/worldpay.php on line 197

I've also spoke to Worldpay (again) and they keep saying that there is no issue in the payment response they are sending back and that the issue is on Opencart's side and that it is likely something with how the webhook is being interpreted..

I've attached the file which these 2 errors relate to, from what I can see it seems the Order Status ID is not being recognized for some reason and therefore resulting in the issue?

Any help is much appreciated as it's causing major problems with customers. Thanks!

Instructions removed.

Thanks Straightlight, I tried implementing the changes you posted but ran into some issues.. I'm using V.2.3.0.2, not sure if the fixes you posted work for my version?

1) there is no admin/view/template/extension/payment/worldpay.twig file so I could not update it.
2) After updating the rest as per your instructions I re-installed the Worldpay module and enabled it but it won't enable now. Everytime I save the module it appears as disabled (and does not work on front-end).

Any idea how it can be resolved please?

That's what happens when you forget to check the breadcrumbs on the forum. Instructions removed, thanks for letting me know.

Based on the code right above that error message, it would appear that the "paymentStatus" part of the response isn't meeting one of the cases in the code (e.g. SUCCESS, FAILED, etc.). Thus, the $order_status_id variable doesn't get set, which is why those error messages appear.

Try logging the $message variable to see what's included in it, and if the "paymentStatus" variable names have changed. If they have, you should change it in that code block. To log that $message variable, you'd do an edit like this:


If the "paymentStatus" isn't set in there, you might be able to use some other data to determine what the order status is. Also, since getting that data requires file_get_contents(), make sure that allow_url_fopen is enabled on your server.

Hope that helps

Better to add a prefix so that users can track the lines more easily from the OC admin error logs:

Thanks for the help, the issue just occurred on another order today (after working okay for the last 4 orders).

Looking at the error log I'm attaching a screenshot of the data recorded.. The order code has been replaced but I set them differently just to show that both instances had the status of "SUCCESS" but only one order was recorded.

Both orders are from the same client, but having got the error first time around, they went back and placed the same order again.

Can anyone help on the above issue please?

Thanks!

Update:

Having looked into it further I see that the orders that are giving the customer the error are being saved to the database with order_status_id of '0'. So for some reason they are being treated as missing orders? Any reasons why?

zollgut wrote: ↑

Mon Mar 05, 2018 10:23 pm

Update:

Having looked into it further I see that the orders that are giving the customer the error are being saved to the database with order_status_id of '0'. So for some reason they are being treated as missing orders? Any reasons why?

I don't see anywhere from your above reply where the results based on the codes I've posted above are showing in your screenshot.

Sorry, I'm not sure either so I may not have sent you what's needed to debug?

The last screenshot I sent was of a single customer who had to place the order twice, for it to go through correctly. I copied and pasted the values from the error log in a spreadsheet for clear comparison.

I don't see any other values relating to the payment status in the log file. The lines directly relating to the problematic order are:

------------

2018-03-05 12:24:08 - PHP Notice: Undefined index: firstname in /vqmod/vqcache/vq2-system_storage_modification_catalog_model_checkout_order.php on line 834
2018-03-05 12:24:08 - PHP Notice: Undefined index: lastname in /vqmod/vqcache/vq2-system_storage_modification_catalog_model_checkout_order.php on line 834
2018-03-05 12:24:09 - Array
(
[notificationEventType] => ORDER_STATE_CHANGE
[orderCode] => 12345
[paymentStatus] => SUCCESS
[environment] => LIVE
)

2018-03-05 12:24:09 - PHP Warning: Cannot modify header information - headers already sent by (output started at /catalog/controller/startup/error.php:34) in /system/library/response.php on line 12

I hope that helps. Thanks!

Caused by an installed extension. catalog/model/checkout/order.php's core file contains 808 lines.

Thanks for that. I've gone through the added modules and located the vqMod which affects that file and have disabled it hopefully it resolves the issue.