Nair Posted August 18, 2020 Share Posted August 18, 2020 Hello All, From last 15-20 days by website which is on 1.7.6.4 has a very weird issue. Most of my customers while placing the order, seems to go through payment successfully (payment gateway), however the order isnt created, both in the back office or in the user order history. Most of the time, the order cart is intact under that custom account. After enabling the debug on the payment page the attached error was seen. What exactly it means? (1/1) UndefinedMethodException Attempted to call an undefined method named "edit" of class "Razorpay\Api\Collection". in razorpay.php line 248 at Razorpay->hookOrderConfirmation(array('order' => object(Order), 'cookie' => object(Cookie), 'cart' => object(Cart), 'altern' => 1))in Hook.php line 970 at HookCore::coreCallHook(object(Razorpay), 'hookorderConfirmation', array('order' => object(Order), 'cookie' => object(Cookie), 'cart' => object(Cart), 'altern' => 1))in Hook.php line 359 at HookCore::callHookOn(object(Razorpay), 'displayOrderConfirmation', array('order' => object(Order), 'cookie' => object(Cookie), 'cart' => object(Cart), 'altern' => 1))in Hook.php line 907 at HookCore::exec('displayOrderConfirmation', array('order' => object(Order), 'cookie' => object(Cookie), 'cart' => object(Cart), 'altern' => 1))in OrderConfirmationController.php line 126 at OrderConfirmationControllerCore->displayOrderConfirmation(object(Order))in OrderConfirmationController.php line 96 at OrderConfirmationControllerCore->initContent()in Controller.php line 292 at ControllerCore->run()in Dispatcher.php line 515 at DispatcherCore->dispatch()in index.php line 28 Link to comment Share on other sites More sharing options...
musicmaster Posted August 20, 2020 Share Posted August 20, 2020 This a module specific problem. So you should ask the maker of this Razorpay module. Link to comment Share on other sites More sharing options...
Nair Posted August 20, 2020 Author Share Posted August 20, 2020 Hi, i have 2 payment gateway modules, the error comes on both, depending on which one customer selects. Link to comment Share on other sites More sharing options...
musicmaster Posted August 20, 2020 Share Posted August 20, 2020 The way payment modules work is that your shop gives the payment provider a link back. When the payment is finished the payment provider call this link and the shop converts the cart into an order and registers that as paid. Obviously something goes wrong in that process. Link to comment Share on other sites More sharing options...
Nair Posted August 21, 2020 Author Share Posted August 21, 2020 10 hours ago, musicmaster said: The way payment modules work is that your shop gives the payment provider a link back. When the payment is finished the payment provider call this link and the shop converts the cart into an order and registers that as paid. Obviously something goes wrong in that process. Hello, You are right, something goes wrong during that process. Interestingly some orders are creating, some are not so the behaviour is not consistent. Now apart from these payment gateway module my website had a testimonial module as well, when that was enabled the same error was thrown showing that module (error attached), i am assuming that testimonial module was also involved during that call back process. WHen this module was disabled debug started showing the error with payment module. Could this be due to some delay in that call back process which when gets timed out the error comes, and when no delay the order is created? Link to comment Share on other sites More sharing options...
musicmaster Posted August 21, 2020 Share Posted August 21, 2020 It could be anything. Long ago (still PS 1.4) I had a shop where some variable was not set right in the backlink given to the payment provider. As a result the call back didn't have a valid cart number to upgrade. I assume there are limits, but normally the delay shouldn't be an issue. Link to comment Share on other sites More sharing options...
Nair Posted August 22, 2020 Author Share Posted August 22, 2020 The shop was upgraded almost 4 months back, the issue started about 25 days back, why would that be? Link to comment Share on other sites More sharing options...
rvkvino Posted August 24, 2020 Share Posted August 24, 2020 (edited) Same problem happening to me also, I'm using Payu and Techprocess payment gateway for my shop. Payment getting successful in gateway admin dashboard but order not creating in back office.After payment get successful it's navigating to mysitesite/cart page. But this showing empty cart because after payment successful it's getting clear and not creating order. Can any one help on this. Some times it's creating order and most of the time order not creating. Edited August 24, 2020 by rvkvino (see edit history) Link to comment Share on other sites More sharing options...
musicmaster Posted August 24, 2020 Share Posted August 24, 2020 Check the error log of the server. Because this is a callback you won't see error screens. Link to comment Share on other sites More sharing options...
olesen Posted August 24, 2020 Share Posted August 24, 2020 Same problem, happens to me too. I use Bambora as a payment gateway in my store. Payment will be successful, but the order will not be created in the back office. The order was left as a basket left behind. Most orders go through but this is a new issue I have not seen before switching to prestashop version 1.7.6.7 Link to comment Share on other sites More sharing options...
rvkvino Posted August 24, 2020 Share Posted August 24, 2020 @musicmaster I have checked the error log I have found the following errors on the log, Is this will get affect the order creation? [24-Aug-2020 12:41:31 Asia/Kolkata] PHP Fatal error: Uncaught --> Smarty: Unable to load template 'module:Paynimo/views/templates/front/validation_new.tpl' <-- thrown in /home/asdarmavanain/public_html/e/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php on line 195 [24-Aug-2020 13:01:20 Asia/Kolkata] PHP Notice: Undefined index: PS_CATALOG_MODE in /home/asdarmavanain/public_html/e/var/cache/prod/smarty/compile/ca/05/e8/ca05e847a9e00ac38609beb082ba8d72cd6d6330_0.file._select_payment.tpl.php on line 25 [24-Aug-2020 13:01:20 Asia/Kolkata] PHP Notice: Trying to get property of non-object in /home/asdarmavanain/public_html/e/var/cache/prod/smarty/compile/ca/05/e8/ca05e847a9e00ac38609beb082ba8d72cd6d6330_0.file._select_payment.tpl.php on line 25 [24-Aug-2020 13:04:28 Asia/Kolkata] PHP Notice: Undefined index: status in /home/asdarmavanain/public_html/e/modules/zsms/zsms.php on line 535 [24-Aug-2020 13:04:28 Asia/Kolkata] PHP Notice: Undefined property: Address::$name in /home/asdarmavanain/public_html/e/modules/zsms/zsms.php on line 645 [24-Aug-2020 13:04:28 Asia/Kolkata] PHP Notice: Undefined property: Address::$name in /home/asdarmavanain/public_html/e/modules/zsms/zsms.php on line 667 [24-Aug-2020 13:04:28 Asia/Kolkata] PHP Notice: Undefined variable: state in /home/asdarmavanain/public_html/e/modules/zsms/zsms.php on line 697 [24-Aug-2020 13:19:33 Asia/Kolkata] PHP Notice: Undefined index: PS_CATALOG_MODE in /home/asdarmavanain/public_html/e/var/cache/prod/smarty/compile/ca/05/e8/ca05e847a9e00ac38609beb082ba8d72cd6d6330_0.file._select_payment.tpl.php on line 25 [24-Aug-2020 13:19:33 Asia/Kolkata] PHP Notice: Trying to get property of non-object in /home/asdarmavanain/public_html/e/var/cache/prod/smarty/compile/ca/05/e8/ca05e847a9e00ac38609beb082ba8d72cd6d6330_0.file._select_payment.tpl.php on line 25 [24-Aug-2020 13:20:33 Asia/Kolkata] PHP Notice: Undefined index: PS_CATALOG_MODE in /home/asdarmavanain/public_html/e/var/cache/prod/smarty/compile/ca/05/e8/ca05e847a9e00ac38609beb082ba8d72cd6d6330_0.file._select_payment.tpl.php on line 25 [24-Aug-2020 13:20:33 Asia/Kolkata] PHP Notice: Trying to get property of non-object in /home/asdarmavanain/public_html/e/var/cache/prod/smarty/compile/ca/05/e8/ca05e847a9e00ac38609beb082ba8d72cd6d6330_0.file._select_payment.tpl.php on line 25 [24-Aug-2020 13:55:19 Asia/Kolkata] PHP Notice: Undefined index: PS_CATALOG_MODE in /home/asdarmavanain/public_html/e/var/cache/prod/smarty/compile/ca/05/e8/ca05e847a9e00ac38609beb082ba8d72cd6d6330_0.file._select_payment.tpl.php on line 25 [24-Aug-2020 13:55:19 Asia/Kolkata] PHP Notice: Trying to get property of non-object in /home/asdarmavanain/public_html/e/var/cache/prod/smarty/compile/ca/05/e8/ca05e847a9e00ac38609beb082ba8d72cd6d6330_0.file._select_payment.tpl.php on line 25 [24-Aug-2020 13:55:40 Asia/Kolkata] PHP Notice: Undefined index: status in /home/asdarmavanain/public_html/e/modules/zsms/zsms.php on line 535 [24-Aug-2020 13:55:40 Asia/Kolkata] PHP Notice: Undefined property: Address::$name in /home/asdarmavanain/public_html/e/modules/zsms/zsms.php on line 645 [24-Aug-2020 13:55:40 Asia/Kolkata] PHP Notice: Undefined property: Address::$name in /home/asdarmavanain/public_html/e/modules/zsms/zsms.php on line 667 [24-Aug-2020 13:55:40 Asia/Kolkata] PHP Notice: Undefined variable: state in /home/asdarmavanain/public_html/e/modules/zsms/zsms.php on line 697 [24-Aug-2020 14:25:43 Asia/Kolkata] PHP Fatal error: Uncaught --> Smarty: Unable to load template 'module:Paynimo/views/templates/front/validation_new.tpl' <-- thrown in /home/asdarmavanain/public_html/e/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php on line 195 Link to comment Share on other sites More sharing options...
musicmaster Posted August 24, 2020 Share Posted August 24, 2020 4 minutes ago, rvkvino said: @musicmaster I have checked the error log I have found the following errors on the log, Is this will get affect the order creation? [24-Aug-2020 13:55:40 Asia/Kolkata] PHP Notice: Undefined index: status in /home/asdarmavanain/public_html/e/modules/zsms/zsms.php on line 535 [24-Aug-2020 13:55:40 Asia/Kolkata] PHP Notice: Undefined property: Address::$name in /home/asdarmavanain/public_html/e/modules/zsms/zsms.php on line 645 [24-Aug-2020 13:55:40 Asia/Kolkata] PHP Notice: Undefined property: Address::$name in /home/asdarmavanain/public_html/e/modules/zsms/zsms.php on line 667 [24-Aug-2020 13:55:40 Asia/Kolkata] PHP Notice: Undefined variable: state in /home/asdarmavanain/public_html/e/modules/zsms/zsms.php on line 697 [24-Aug-2020 14:25:43 Asia/Kolkata] PHP Fatal error: Uncaught --> Smarty: Unable to load template 'module:Paynimo/views/templates/front/validation_new.tpl' <-- thrown in /home/asdarmavanain/public_html/e/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php on line 195 This certainly doesn't look healthy. As many errors concern the zsms module I would start disabling that. Link to comment Share on other sites More sharing options...
rvkvino Posted August 24, 2020 Share Posted August 24, 2020 (edited) @musicmaster After I have disabled SMS module I have checked the error log it's showing the error in [24-Aug-2020 18:15:45 Asia/Kolkata] PHP Fatal error: Uncaught --> Smarty: Unable to load template 'module:Paynimo/views/templates/front/validation_new.tpl' <-- thrown in /home/asdarmavanain/public_html/e/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php on line 195 But when I check this path module file is available in that path. Edited August 24, 2020 by rvkvino (see edit history) Link to comment Share on other sites More sharing options...
musicmaster Posted August 24, 2020 Share Posted August 24, 2020 7 minutes ago, rvkvino said: Unable to load template 'module:Paynimo/views/templates/front/validation_new.tpl' <-- thrown in /home/asdarmavanain/public_html/e/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php on line 195 It could be anything. It could be the ":" in "module:Paynimo". It could also be the capital "P" in "Paynimo". It could even be that the file is there and recognized as such but that it is somehow defect so that it cannot be loaded as a valid template file. Link to comment Share on other sites More sharing options...
rvkvino Posted August 24, 2020 Share Posted August 24, 2020 What should I need to do in this case, whether I need to write tolowercase of file name or may I update the one more folder in the name of Paynimo Link to comment Share on other sites More sharing options...
musicmaster Posted August 24, 2020 Share Posted August 24, 2020 There is no easy answer. When this was my system I would research where the error exactly came from. That means text searches and experiments. The alternative is to ask the maker of the Paynimo module. Link to comment Share on other sites More sharing options...
tomerg3 Posted August 24, 2020 Share Posted August 24, 2020 I would first do a test to see what is the root cause, this payment module, or you shop. If you are able to reproduce the issue with the razor payment module, try to do the exact same thing with the built in Pay By Check module. If you see the same error, the problem is with your shop. If the order is processed correctly, then the issue is with the razor module. Link to comment Share on other sites More sharing options...
olesen Posted August 26, 2020 Share Posted August 26, 2020 I think the problem's maby is in the Prestashop cache ? Tried to delete two folders below. -"/app/cache/dev" -"/app/cache/prod" Hope it could help. Link to comment Share on other sites More sharing options...
Nair Posted August 26, 2020 Author Share Posted August 26, 2020 4 hours ago, olesen said: I think the problem's maby is in the Prestashop cache ? Tried to delete two folders below. -"/app/cache/dev" -"/app/cache/prod" Hope it could help. Hello Olesen, Thank you for the suggestion. After reading through some of the posts in the forum here and with the behaviour while i tested, I also suspected cache to be a possible culprit and had deleted /var/cache/dev & /var/cache/prod i will try your suggestion, by the way hope deleting the /app/cache/dev & prod should be safe? Thank you. Link to comment Share on other sites More sharing options...
tomerg3 Posted August 26, 2020 Share Posted August 26, 2020 Deleting cache is generally safe, unless there's a new error in your shop, which is not showing up as the cached code is being served. It's always best to create a backup before deleting anything. Link to comment Share on other sites More sharing options...
rvkvino Posted August 27, 2020 Share Posted August 27, 2020 (edited) @olesen I have deleted and checked the cache/dev and cache/prod folders still order not creating most of the time after successful payment. For my 10 successful payment 1 or 2 orders are creating successful others now we are doing manually after checked the gateway dashboard we are confirming from backoffice. These manual process are taking more time and resources. Please help any one to solve this issue permanently. Now in my error log page showing below, [27-Aug-2020 08:26:37 Asia/Kolkata] PHP Fatal error: Uncaught --> Smarty: 0():Missing '$template' parameter <-- thrown in /home/public_html/e/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php on line 177 [27-Aug-2020 08:32:41 Asia/Kolkata] PHP Fatal error: Uncaught --> Smarty: 0():Missing '$template' parameter <-- thrown in /home/public_html/e/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php on line 177 [27-Aug-2020 09:33:43 Asia/Kolkata] PHP Fatal error: Uncaught --> Smarty: 0():Missing '$template' parameter <-- thrown in /home/public_html/e/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php on line 177 Edited August 27, 2020 by rvkvino (see edit history) Link to comment Share on other sites More sharing options...
musicmaster Posted August 27, 2020 Share Posted August 27, 2020 I won't know whether this will work. But try doing a text search in the cache for the word "Missing". It might help finding the place of the bug. Link to comment Share on other sites More sharing options...
rvkvino Posted August 28, 2020 Share Posted August 28, 2020 Hello, I couldn't solve the issue on this yet. Can you please any one give the solution to solve this issue. Link to comment Share on other sites More sharing options...
Nair Posted August 28, 2020 Author Share Posted August 28, 2020 (edited) On 8/24/2020 at 12:53 PM, rvkvino said: Same problem happening to me also, I'm using Payu and Techprocess payment gateway for my shop. Payment getting successful in gateway admin dashboard but order not creating in back office.After payment get successful it's navigating to mysitesite/cart page. But this showing empty cart because after payment successful it's getting clear and not creating order. Can any one help on this. Some times it's creating order and most of the time order not creating. As i had mentioned my website had both Payu and Razorpay payment gateway, my observation in the last 7-10 days is that most of the orders that are failing were on Payumoney, all orders were created successfully with Razorpay. I have disabled the Payumoney gateway for the time being and will observe for the next few days to see if i see the issue again. Another observation - as a customer i buy grocery online these days and the payment gateway there as well is payumoney and i had the same issue for last 3-4 weeks, i think its a possible issue with payumoney module/infrastructure. When i raised a support ticket almost a month back with payumoney they closed it everytime stating its not their issue, after i presisted for a month they told me that they eventually told me that they are working on a new module and would be published soon, however they refused to give me a date. Edited August 28, 2020 by binesh (see edit history) Link to comment Share on other sites More sharing options...
Nair Posted September 3, 2020 Author Share Posted September 3, 2020 On 8/28/2020 at 10:43 AM, binesh said: As i had mentioned my website had both Payu and Razorpay payment gateway, my observation in the last 7-10 days is that most of the orders that are failing were on Payumoney, all orders were created successfully with Razorpay. I have disabled the Payumoney gateway for the time being and will observe for the next few days to see if i see the issue again. Another observation - as a customer i buy grocery online these days and the payment gateway there as well is payumoney and i had the same issue for last 3-4 weeks, i think its a possible issue with payumoney module/infrastructure. When i raised a support ticket almost a month back with payumoney they closed it everytime stating its not their issue, after i presisted for a month they told me that they eventually told me that they are working on a new module and would be published soon, however they refused to give me a date. It's been a week and my website has been only with Razorpay payment gateway module and all payments vs order were in sync, no customer complaining and we verified as well. So it was indeed an issue with Payumoney module. Link to comment Share on other sites More sharing options...
accessorybee01 Posted September 5, 2020 Share Posted September 5, 2020 This is really important, Experts PLEASE READ IN FULL!! Same issue had been reported with CCAvenue payment module from 11th august 2020. Some Customers reported that they got an error page after making an payment, Possibly at the time of redirection after payment processing to site. However none of them had provided the error screen. Also this behavior is inconsistent as whenever we try to make a purchase the order got updated in website, Tried three times different days with different payment methods like Credit Card, Debit Card, Wallets and choosing different shipping methods but every time we order the order got updated successfully in back office! I contacted gateway CCAvenue but they say everything is fine from them (By the way most stupid customer support these days as they are only available through chat due to Covid-19, no support through call and same is with Bigrock but most of the people from Big Rock are knowledgeable ) Also one thing I am using Bigrock and they had stopped the version of PHP 7.0 and 7.1 from 12th of August and we changed the version of php to 7.3 on 11th of august and thats where all these problems related to payments started. After that I updated the prestashop from 1.7.6.1 to 1.7.6.7 , updated modules and theme to the latest version to see if anything will change but no improvement. So before 5-6 days around 31st august I enabled debug mode in performance tab (Which resulted in the last worst thing that could happen) and after enabling that, errors started showing everywhere in the backoffice and few place in front office and was unable to open performance tab/page again to disable debug option as the error page opens up. After searching a bit on google about the error it was related to the incorrect Composer version installed as the new php version dsn't interpret some tags or escape character as it with older versions. So the suggestion was to upgrade the composer. Got instructions to update the composer and found that it was not updating and showing error upon installation that permission denied to write at directory. This is because I am on shared hosting and to do so I need to have a root level administrator rights or a Private Server like VPS kind of plan!! I contacted Bigrock and they denied that they cant update the composer but they figured out the version of PHP which I was earlier using and they said it was 5.6 and they changed it to 5.6 from there side as now in cpanel the only versions for php to select are 7.0/7.1 / 7.2/ 7.3/ 7.4 and just after they changed the php version to 5.6 all the errors are gone and first thing I did was that I disabled the debug mode I had found that the composer versions are compatible with specific php versions only for which they are developed or targeted at and they both needs to be changed else the errors will start firing up wherever there will be any incompatibility in code will happen. This might be the main reason that we are getting errors now as the php versions are abandoned and forcefully change to 7.3 by default by different hosting providers and bigrock customer support told me that the php 5.6 will stop working soon and they will stop it permanently might be from 31st September. I request to developers related to Prestashop to help resolve this issue else not thousands lakhs of store owners who are on shared hosting will be badly affected and unable to use their website with Prestashop. Even I am thinking of migrating to Magento even after my love for Prestashop! Please Help.... 1 Link to comment Share on other sites More sharing options...
Matt75 Posted September 5, 2020 Share Posted September 5, 2020 4 minutes ago, accessorybee01 said: I request to developers related to Prestashop to help resolve this issue else not thousands lakhs of store owners who are on shared hosting will be badly affected and unable to use their website with Prestashop. Even I am thinking of migrating to Magento even after my love for Prestashop! Current PrestaShop version support up to PHP 7.2 and PHP 7.2 is still supported until November 2020 : https://www.php.net/supported-versions.php PrestaShop 1.7.7 currently in beta 2 will support PHP 7.3 : https://devdocs.prestashop.com/1.7/basics/installation/system-requirements/#php-compatibility-chart PrestaShop is an open source project, maintenance is made by PrestaShop SA and community, this software cannot evolve quicker if community doesn’t contribute more to the source code. https://devdocs.prestashop.com/1.7/contribute/ More information about PrestaShop 1.7.7 : https://build.prestashop.com/news/prestashop-1-7-7-0-beta2-release/ We strongly recommend to test this version on a development environment with your shop to test it and report bugs in order to help us to make the more robust release as possible. https://devdocs.prestashop.com/1.7/contribute/contribute-reporting-issues/ We cannot do everything alone due to limited resources, we need community and if no one contribute we cannot deliver faster. So please help PrestaShop first and PrestaShop will help you, together we are stronger. Link to comment Share on other sites More sharing options...
musicmaster Posted September 6, 2020 Share Posted September 6, 2020 On 9/5/2020 at 1:23 PM, Matt75 said: Current PrestaShop version support up to PHP 7.2 and PHP 7.2 is still supported until November 2020 : https://www.php.net/supported-versions.php PrestaShop 1.7.7 currently in beta 2 will support PHP 7.3 : https://devdocs.prestashop.com/1.7/basics/installation/system-requirements/#php-compatibility-chart PrestaShop is an open source project, maintenance is made by PrestaShop SA and community, this software cannot evolve quicker if community doesn’t contribute more to the source code. https://devdocs.prestashop.com/1.7/contribute/ More information about PrestaShop 1.7.7 : https://build.prestashop.com/news/prestashop-1-7-7-0-beta2-release/ We strongly recommend to test this version on a development environment with your shop to test it and report bugs in order to help us to make the more robust release as possible. https://devdocs.prestashop.com/1.7/contribute/contribute-reporting-issues/ We cannot do everything alone due to limited resources, we need community and if no one contribute we cannot deliver faster. So please help PrestaShop first and PrestaShop will help you, together we are stronger. Why is the Prestashop company having so much trouble keeping up with the newest PHP versions where Thirty Bees has been able to do so with much less resources? Link to comment Share on other sites More sharing options...
Matt75 Posted September 6, 2020 Share Posted September 6, 2020 1 hour ago, musicmaster said: Why is the Prestashop company having so much trouble keeping up with the newest PHP versions where Thirty Bees has been able to do so with much less resources? Due to introduction of dependencies like some components of the Symfony framework and because we have more restrictions about breaking change in order to keep modules & themes compliant as much as possible. About support of PHP 7.3, please follow https://github.com/PrestaShop/PrestaShop/issues/12461 About support of PHP 7.4, please follow https://github.com/PrestaShop/PrestaShop/issues/16477 Link to comment Share on other sites More sharing options...
accessorybee01 Posted September 6, 2020 Share Posted September 6, 2020 2 hours ago, Matt75 said: Due to introduction of dependencies like some components of the Symfony framework and because we have more restrictions about breaking change in order to keep modules & themes compliant as much as possible. About support of PHP 7.3, please follow https://github.com/PrestaShop/PrestaShop/issues/12461 About support of PHP 7.4, please follow https://github.com/PrestaShop/PrestaShop/issues/16477 On 9/5/2020 at 4:53 PM, Matt75 said: Current PrestaShop version support up to PHP 7.2 and PHP 7.2 is still supported until November 2020 : https://www.php.net/supported-versions.php PrestaShop 1.7.7 currently in beta 2 will support PHP 7.3 : https://devdocs.prestashop.com/1.7/basics/installation/system-requirements/#php-compatibility-chart PrestaShop is an open source project, maintenance is made by PrestaShop SA and community, this software cannot evolve quicker if community doesn’t contribute more to the source code. https://devdocs.prestashop.com/1.7/contribute/ More information about PrestaShop 1.7.7 : https://build.prestashop.com/news/prestashop-1-7-7-0-beta2-release/ We strongly recommend to test this version on a development environment with your shop to test it and report bugs in order to help us to make the more robust release as possible. https://devdocs.prestashop.com/1.7/contribute/contribute-reporting-issues/ We cannot do everything alone due to limited resources, we need community and if no one contribute we cannot deliver faster. So please help PrestaShop first and PrestaShop will help you, together we are stronger. What should be done now Its been a month on this 11th and we are not getting any order updated on backoffice and all this thing stopped suddenly without poking around files or settings as store owners didnt have time to even update a module but think what would be the situation of store owners like us!! If you pay even $1 on any website and your order will not show up in their website after payment then what will you or anyone think?? as you said Please help Prestashop first, then please tell me what information you need. The version I am using is 1.7.6.7 and same issue was there in 1.7.6.1 and due to the issue we updated the Prestashop to latest stable release available but issue is still there. So please tell me what information you need to resolve this bug and most important when we try to make payment on website or do a Live Purchase then order shows up in backoffice!! Now this is making us like pulling hair out of head. Please help in resolving issue. Link to comment Share on other sites More sharing options...
Matt75 Posted September 6, 2020 Share Posted September 6, 2020 16 minutes ago, accessorybee01 said: So please tell me what information you need to resolve this bug and most important when we try to make payment on website or do a Live Purchase then order shows up in backoffice!! Now this is making us like pulling hair out of head. Please help in resolving issue. I cannot help you on this, you should contact your hosting provider to be sure you use a PHP version supported by PrestaShop and retrieve error logs, then contact customer service or developer of your payment module. RazorPay module is not developed by PrestaShop and I never use it unfortunately. Link to comment Share on other sites More sharing options...
Nair Posted September 7, 2020 Author Share Posted September 7, 2020 8 hours ago, Matt75 said: I cannot help you on this, you should contact your hosting provider to be sure you use a PHP version supported by PrestaShop and retrieve error logs, then contact customer service or developer of your payment module. RazorPay module is not developed by PrestaShop and I never use it unfortunately. Infact it does not appear to be a specific module issue of payment gateways, so far with the posts from many, there are multiple payment gateways that are showing this behaviour, for sure there is some issue post the payment is successful and the call back happens (delay??) to the prestashop website for order creation and confirmation. Payment gateway modules weren't changed/updated. Anyone seeing the issue has webhook enabled? May be that can help. For me Razorpay is working well, but Payumoney isn't. Link to comment Share on other sites More sharing options...
accessorybee01 Posted September 7, 2020 Share Posted September 7, 2020 11 hours ago, binesh said: Infact it does not appear to be a specific module issue of payment gateways, so far with the posts from many, there are multiple payment gateways that are showing this behaviour, for sure there is some issue post the payment is successful and the call back happens (delay??) to the prestashop website for order creation and confirmation. Payment gateway modules weren't changed/updated. Anyone seeing the issue has webhook enabled? May be that can help. For me Razorpay is working well, but Payumoney isn't. can you please tell which Prestashop version you are using and which php version are you using for domain?? You can find Prestashop version in upper right corner in backoffice and php version in cpanel and then in myphpadmin and then there will be php version written next to domain name in a list form. Link to comment Share on other sites More sharing options...
Nair Posted September 8, 2020 Author Share Posted September 8, 2020 10 hours ago, accessorybee01 said: can you please tell which Prestashop version you are using and which php version are you using for domain?? You can find Prestashop version in upper right corner in backoffice and php version in cpanel and then in myphpadmin and then there will be php version written next to domain name in a list form. Prestashop 1.7.6.4 and PHP 7.2 Link to comment Share on other sites More sharing options...
Nick Posted September 21, 2020 Share Posted September 21, 2020 i think the problem is with MASTERCARD and a new 2 factor transaction mode call ''Mastercard® Identity Check™''. If you can test your modules with VISA cards you want have a problem .Because i have the same issue .Looking for sollution Link to comment Share on other sites More sharing options...
Symphony Posted October 29, 2020 Share Posted October 29, 2020 We are experiencing the same issues without a solution:- · Successful payments not converting cart into sale. · Customer gets 'fatal error' or 'There has been a problem processing your transaction, no variables have been passed to the result handler - please try again' · As a result, on some occasions, the customer will reattempt the purchase as suggested, and end up duplicating payments that need to be refunded. PS Version:- 1.7.6.8 (upgraded from 1.7.4.3 about two weeks ago, and worked fine for 10 days) PHP version:- 7.1 What we know:- · Issue happens with more than one payment module, so if the module is at fault then more than one module is suffering the same flaw. · It isn't related to card type (as suggested elsewhere in the thread) as we have had the issue occur with different card types, and also the same card deliver different results. · Issue occurred when site was running with Smarty cache and Litespeed enabled · Hosts suggest it may be an issue with Smarty Cache based on one of the error messages. I believe Smarty Cache was fine on its own for a while, but can't be certain exactly when I turned it back on, and when Litespeed was re-enabled. What is certain is that the issue seemed to be far more frequent with both Smarty Cache and Litespeed. · Deleted contents of var/cache folder before the below error message mentioning var/cache · All caches are now disabled on the site, and although we have still had a couple of instances they are far less frequent. It is possible they were existing carts, and perhaps the user's browser cache still caused an issue? Or it could just be luck. Either way, I don't want to activate either cache and so the site is sluggish. If anyone can help that woudl be greatly appreciated as I am very close to migrating to a more stable platform; capturing payments and processing orders is the raison d'etre of an e-commerce site, so it is a critical failure for a business when this aspect falls over. A sample of some of the log entries at the point of failures (I have more logs I think if necessary): 2020-10-29 00:06:22.357577 [NOTICE] [12973] [195.171.28.98:33105:HTTP2-23#APVH_symphonymusicstore.co.uk:443] [STDERR] PHP Fatal error: Uncaught Symfony\Component\Filesystem\Exception\IOException: Failed to remove directory "/home/symphony/public_html/var/cache/prod/smarty": rmdir(/home/symphony/public_html/var/cache/prod/smarty): Directory not empty. in /home/symphony/public_html/vendor/symfony/symfony/src/Symfony/Component/Filesystem/Filesystem.php:180 2020-10-28 18:01:53.130566 [NOTICE] [2572] [77.44.116.163:59623:HTTP2-1#APVH_symphonymusicstore.co.uk:443] [STDERR] PHP Notice: Undefined property: DbPDO::$link in /home/symphony/public_html/classes/db/DbPDO.php on line 156 2020-10-28 18:01:53.130666 [NOTICE] [2572] [77.44.116.163:59623:HTTP2-1#APVH_symphonymusicstore.co.uk:443] [STDERR] PHP Fatal error: Uncaught Error: Call to a member function query() on null in /home/symphony/public_html/classes/db/DbPDO.php:156 The following fatal error seems to coincide with one of the payment failures provided. ===== [28-Oct-2020 15:34:31 Europe/London] PHP Fatal error: Uncaught PrestaShop\PrestaShop\Core\Product\Search\Exception\InvalidSortOrderDirectionException: Invalid SortOrder direction ``. Expecting one of: `ASC`, `DESC`, or `RANDOM`. in /hom e/symphony/public_html/src/Core/Product/Search/SortOrder.php:199 Stack trace: #0 /home/symphony/public_html/src/Core/Product/Search/SortOrder.php(67): PrestaShop\PrestaShop\Core\Product\Search\SortOrder->setDirection(NULL) #1 /home/symphony/public_html/src/Core/Product/Search/SortOrder.php(125): PrestaShop\PrestaShop\Core\Product\Search\SortOrder->__construct('160', NULL, NULL) #2 /home/symphony/public_html/classes/controller/ProductListingFrontController.php(286): PrestaShop\PrestaShop\Core\Product\Search\SortOrder::newFromString('160') #3 /home/symphony/public_html/classes/controller/ProductListingFrontController.php(580): ProductListingFrontControllerCore->getProductSearchVariables() #4 /home/symphony/public_html/controllers/front/listing/CategoryController.php(137): ProductListingFrontControllerCore->doProductSearch('catalog/l in /home/symphony/public_html/src/Core/Product/Search/SortOrder.php on line 199 [28-Oct-2020 15:34:32 Europe/London] PHP Notice: Undefined offset: 1 in /home/symphony/public_html/src/Core/Product/Search/SortOrder.php on line 123 [28-Oct-2020 15:34:32 Europe/London] PHP Notice: Undefined offset: 2 in /home/symphony/public_html/src/Core/Product/Search/SortOrder.php on line 123 [28-Oct-2020 15:34:32 Europe/London] PHP Fatal error: Uncaught PrestaShop\PrestaShop\Core\Product\Search\Exception\InvalidSortOrderDirectionException: Invalid SortOrder direction ``. Expecting one of: `ASC`, `DESC`, or `RANDOM`. in /hom e/symphony/public_html/src/Core/Product/Search/SortOrder.php:199 Stack trace: #0 /home/symphony/public_html/src/Core/Product/Search/SortOrder.php(67): PrestaShop\PrestaShop\Core\Product\Search\SortOrder->setDirection(NULL) #1 /home/symphony/public_html/src/Core/Product/Search/SortOrder.php(125): PrestaShop\PrestaShop\Core\Product\Search\SortOrder->__construct('696', NULL, NULL) #2 /home/symphony/public_html/classes/controller/ProductListingFrontController.php(286): PrestaShop\PrestaShop\Core\Product\Search\SortOrder::newFromString('696') #3 /home/symphony/public_html/classes/controller/ProductListingFrontController.php(580): ProductListingFrontControllerCore->getProductSearchVariables() #4 /home/symphony/public_html/controllers/front/listing/CategoryController.php(137): ProductListingFrontControllerCore->doProductSearch('catalog/l in /home/symphony/public_html/src/Core/Product/Search/SortOrder.php on line 199 [28-Oct-2020 15:34:38 Europe/London] PHP Notice: Undefined offset: 1 in /home/symphony/public_html/src/Core/Product/Search/SortOrder.php on line 123 [28-Oct-2020 15:34:38 Europe/London] PHP Notice: Undefined offset: 2 in /home/symphony/public_html/src/Core/Product/Search/SortOrder.php on line 123 [28-Oct-2020 15:34:38 Europe/London] PHP Fatal error: Uncaught PrestaShop\PrestaShop\Core\Product\Search\Exception\InvalidSortOrderDirectionException: Invalid SortOrder direction ``. Expecting one of: `ASC`, `DESC`, or `RANDOM`. in /hom e/symphony/public_html/src/Core/Product/Search/SortOrder.php:199 Stack trace: #0 /home/symphony/public_html/src/Core/Product/Search/SortOrder.php(67): PrestaShop\PrestaShop\Core\Product\Search\SortOrder->setDirection(NULL) #1 /home/symphony/public_html/src/Core/Product/Search/SortOrder.php(125): PrestaShop\PrestaShop\Core\Product\Search\SortOrder->__construct('568', NULL, NULL) #2 /home/symphony/public_html/classes/controller/ProductListingFrontController.php(286): PrestaShop\PrestaShop\Core\Product\Search\SortOrder::newFromString('568') #3 /home/symphony/public_html/classes/controller/ProductListingFrontController.php(580): ProductListingFrontControllerCore->getProductSearchVariables() ===== Link to comment Share on other sites More sharing options...
Symphony Posted October 30, 2020 Share Posted October 30, 2020 (edited) confirmed PHP is 7.1 Edited October 30, 2020 by Symphony was incorrect (see edit history) Link to comment Share on other sites More sharing options...
Symphony Posted October 31, 2020 Share Posted October 31, 2020 (edited) Further update: Since disabling the caches, the incedence rate is much lower. However, we have still had it happen a few times. This suggests that whilst caches may exacerbate the problem, it is not the root cause. With today's occurrence, there was no error generated on the server. The log just showed the handover to the payment module but nothing else: 81.108.18.251 - - [31/Oct/2020:13:15:44 +0000] "GET /order?step=1 HTTP/1.1" 302 0 "https://mms.payzoneonlinepayments.com/" "Mozilla/5.0 (Linux; Android 9; ONEPLUS A6003) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.114 Mobile Safari/537.36" 81.108.18.251 - - [31/Oct/2020:13:15:45 +0000] "GET /cart HTTP/1.1" 200 15890 "https://mms.payzoneonlinepayments.com/" "Mozilla/5.0 (Linux; Android 9; ONEPLUS A6003) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.114 Mobile Safari/537.36" Apparently the cart/payment was open a bit of time - could this be a factor? (And why the problem is far more prevalent when caches are enabled?) Either way, we know it is an issue with either the PS Code, or the module. But if it is the module, it happens with all our payment modules (suggesting they have been developed to a certain spec that now is slighjtly incompatible with 1.7.6) Any idea on this? It is driving me crazy Edited October 31, 2020 by Symphony More information (see edit history) Link to comment Share on other sites More sharing options...
tomerg3 Posted October 31, 2020 Share Posted October 31, 2020 Usually when an order is not generated correctly on multiple payment modules, after the transaction was approved, it is due to an error in the Validate function in PaymentModule class. The most common issues there are related to email (server unable to send them, usually an external or smtp), or an issue with pdf creation. Looking at your logs, it does not seem to be the issue here. The most important step in debugging an issue is to be able to reproduce it, in order to get more information, and to be able to test if it's resolved. If you are not able to recreate the issue, the next best step is to add more debug code to try to identify the root cause when the error happens next. I would add debug code in the payment module, after the payment is done, before the order validation function is called, and after it. I would also add debug code in the order validation function, to better identify where the process breaks. Link to comment Share on other sites More sharing options...
Symphony Posted November 1, 2020 Share Posted November 1, 2020 (edited) Thanks Tomerg3, I will feed this back to the Payment module developer. However, as per my diagnosis so far, this isn't strictly related to the payment module, or if it is, it must be a common error with all the three payment modules we use because the issue occurs irrespective of payment method. I have done some more testing today though and discovered the following: Enabling Litespeed makes the incedence rate increase dramatically, but I don't think it is the root cause. I turned it on today and flushed it and indeed we got a few issues. I didn't turn on smarty cache so that can't be the culprit. But even with Litespeed disabled we get the odd occurence. Instead, I have had some weird behaviour whereby when I logged in to the front office using one of my accounts I use to test transactions, it brought up an abandoned cart that another customer had generated earlier in the day. I did see this happen once last year, but it also happened in the middle of the payment issues last week when an order came through from a completely different name to the payment. I think the whole root cause is due to some issue with carts getting allocated or swapped between customers. If this does happen, then I assume the legitimate customer's order woud fail to complete, as suddenly there is no valid cart to convert. This would explain the payment issues, and the error log. The smarty cache and Litespeed are red herrings because it happens with them disabled, even though it is worse with them on (no doubt as more data is held). Any suggestions what may be causing this behaviour of carts getting reallocated to different customers, as I believe if we figure that, the whole payment problem will be sorted. I am awaiting error logs from the server guys. Edited November 1, 2020 by Symphony mistake (see edit history) Link to comment Share on other sites More sharing options...
Symphony Posted November 1, 2020 Share Posted November 1, 2020 The error log is as follows (lots of mentions of smarty cache, even though its disabled?) - [01/Nov/2020:20:56:18 +0000] "POST /index.php?fc=module&module=takepayments&controller=results HTTP/1.1" 302 0 "https://mms.payzoneonlinepayments.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36" 2a02:c7f:3885:9600:b5b7:5e6c:3bed:e8b1 - - [01/Nov/2020:20:56:18 +0000] "GET /order?step=1 HTTP/1.1" 302 0 "https://mms.payzoneonlinepayments.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36" 2a02:c7f:3885:9600:b5b7:5e6c:3bed:e8b1 - - [01/Nov/2020:20:56:19 +0000] "GET /cart HTTP/1.1" 200 15806 "https://mms.payzoneonlinepayments.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36" ================================ ============================== [01-Nov-2020 20:54:33 Europe/London] PHP Notice: Trying to get property of non-object in /home/symphony/public_html/var/cache/prod/smarty/compile/7a/30/38/7a3038780284d52e9fcd7a66e51e5b86a166106b_2.module.iqitsearchviewstemplatesh.php on line 27 [01-Nov-2020 20:55:22 Europe/London] PHP Notice: Undefined index: search_controller_url in /home/symphony/public_html/var/cache/prod/smarty/compile/7a/30/38/7a3038780284d52e9fcd7a66e51e5b86a166106b_2.module.iqitsearchviewstemplatesh.php on line 27 [01-Nov-2020 20:55:22 Europe/London] PHP Notice: Trying to get property of non-object in /home/symphony/public_html/var/cache/prod/smarty/compile/7a/30/38/7a3038780284d52e9fcd7a66e51e5b86a166106b_2.module.iqitsearchviewstemplatesh.php on line 27 [01-Nov-2020 20:56:25 Europe/London] PHP Notice: Undefined index: search_controller_url in /home/symphony/public_html/var/cache/prod/smarty/compile/7a/30/38/7a3038780284d52e9fcd7a66e51e5b86a166106b_2.module.iqitsearchviewstemplatesh.php on line 27 [01-Nov-2020 20:56:25 Europe/London] PHP Notice: Trying to get property of non-object in /home/symphony/public_html/var/cache/prod/smarty/compile/7a/30/38/7a3038780284d52e9fcd7a66e51e5b86a166106b_2.module.iqitsearchviewstemplatesh.php on line 27 [01-Nov-2020 20:56:33 Europe/London] PHP Notice: Undefined index: search_controller_url in /home/symphony/public_html/var/cache/prod/smarty/compile/7a/30/38/7a3038780284d52e9fcd7a66e51e5b86a166106b_2.module.iqitsearchviewstemplatesh.php on line 27 [01-Nov-2020 20:56:33 Europe/London] PHP Notice: Trying to get property of non-object in /home/symphony/public_html/var/cache/prod/smarty/compile/7a/30/38/7a3038780284d52e9fcd7a66e51e5b86a166106b_2.module.iqitsearchviewstemplatesh.php on line 27 [01-Nov-2020 20:57:30 Europe/London] PHP Notice: Undefined index: search_controller_url in /home/symphony/public_html/var/cache/prod/smarty/compile/7a/30/38/7a3038780284d52e9fcd7a66e51e5b86a166106b_2.module.iqitsearchviewstemplatesh.php on line 27 [01-Nov-2020 20:57:30 Europe/London] PHP Notice: Trying to get property of non-object in /home/symphony/public_html/var/cache/prod/smarty/compile/7a/30/38/7a3038780284d52e9fcd7a66e51e5b86a166106b_2.module.iqitsearchviewstemplatesh.php on line 27 [01-Nov-2020 20:57:43 Europe/London] PHP Notice: Undefined index: search_controller_url in /home/symphony/public_html/var/cache/prod/smarty/compile/7a/30/38/7a3038780284d52e9fcd7a66e51e5b86a166106b_2.module.iqitsearchviewstemplatesh.php on line 27 ============================== Link to comment Share on other sites More sharing options...
tomerg3 Posted November 2, 2020 Share Posted November 2, 2020 Smarty is using cache all the time, you can tell it to recomplie the cache every time, but it will still be used. Those notices (Not errors) are not with smarty, but rather with theme files. It's highly unlikely that carts will get mixed up during the checkout process, on a consistent basis, and increase with cache use. Link to comment Share on other sites More sharing options...
Symphony Posted November 2, 2020 Share Posted November 2, 2020 Thanks Tomerg: With regard to Smarty: we have it set to 'No' in the performance section. What is the purpose of Cache Yes/No if it is used regardless? With regard to the mixing of carts:- This 100% has happened on a few occasions. Yesterday I noticed a customer had added something to their cart (I check every so often as a curiosity to prepare for potential orders). This just happened to be after I had decided to retest LS Cache. When I logged into one of my test customer accounts in the front end to place a small test order, the item the customer had added was showing in my cart. When I checked in the backoffice again, the customer's cart for this item was gone. We have also had legitimate orders come through where the customer had changed (to someone else who co-incidentally had a basket at a similar time). The legitimate customer's basket had gone, and the only way to figure the problem was us to spot on the email from our payment provider the different name, or for the customer to ring to say he had paid for an order but nothing was showing on his account. We had to manually intervene and swap everything over. If carts are occasionally getting stuck between customers (and it seems to happen more when caches are on - but still on occasion when not), that would then also possibly explain why we are having these payment issues that the thread is about; the payment completing has no cart to convert and so hits a dead-end and errors (as per the error in my post from Thursday 11:44). Hope this helps. Link to comment Share on other sites More sharing options...
Nick Posted November 2, 2020 Share Posted November 2, 2020 Link to comment Share on other sites More sharing options...
Symphony Posted November 2, 2020 Share Posted November 2, 2020 Just now, Nick said: Thanks Nick. We are on 7.1 which should be fine for 1.7.6.8 as per above chart Link to comment Share on other sites More sharing options...
Nick Posted November 2, 2020 Share Posted November 2, 2020 about php version and prestashop version Link to comment Share on other sites More sharing options...
Symphony Posted November 2, 2020 Share Posted November 2, 2020 Like I say, we are on 7.1 Link to comment Share on other sites More sharing options...
Nick Posted November 2, 2020 Share Posted November 2, 2020 1 minute ago, Symphony said: Thanks Nick. We are on 7.1 which should be fine for 1.7.6.8 as per above chart 1.7.6 needs 7.2 Link to comment Share on other sites More sharing options...
Symphony Posted November 2, 2020 Share Posted November 2, 2020 I thought the chart appears to suggest that 7.1 is supported. Do you believe it is a PHP version error? Link to comment Share on other sites More sharing options...
Nick Posted November 2, 2020 Share Posted November 2, 2020 php version is causing a lot of strange things but for this problem is responsible the payment module . I have spoke to my programmer of the module and he is preparing an update because of the extra security . Link to comment Share on other sites More sharing options...
Symphony Posted November 2, 2020 Share Posted November 2, 2020 Thanks. I'll refer to the payment module developers Link to comment Share on other sites More sharing options...
Symphony Posted November 2, 2020 Share Posted November 2, 2020 I'll also change php to 7.2 and see what happens. Thanks again Dave Link to comment Share on other sites More sharing options...
olesen Posted November 2, 2020 Share Posted November 2, 2020 Hi Unfortunately still no solution from me 😞 Same problem, happens to me too. I use Bambora as a payment gateway in my store (only one payment modul). Payment will be successful, but the order will not be created in the back office. The order was left as a basket, or undere the customer. Most orders go through but this is a new issue I have not seen before switching to prestashop version 1.7.6.7 If I delete all folders under .\var\cache, there is a tendency for the problem to disappear for a while but come back again. I am also looking for a more durable solution. Link to comment Share on other sites More sharing options...
Symphony Posted November 2, 2020 Share Posted November 2, 2020 Thanks Olesen, At least I am not alone with this. And mine too seems to be since upgrading (1.7.4.3 - 1.7.6.8), and is irrespective of the payment method chosen (we have 3 payment modules active). I do think it is tied into the weird cart mixup issue between customers, but can't be certain Which version PHP are you on? Someone above has suggested moving to 7.2 (I'm on 7.1). Also, are you using any other cache system than PS Smarty cache? Our server uses Litespeed, and the issue is more prevalent when enabled (but does still happen occasionally when disabled). Many thanks, Dave Link to comment Share on other sites More sharing options...
olesen Posted November 2, 2020 Share Posted November 2, 2020 Hi I am using php 7.2. Currently I have disabled all cache. Before, I just used standard cache and CSS cache Link to comment Share on other sites More sharing options...
Symphony Posted November 2, 2020 Share Posted November 2, 2020 Yeah I suspected as such. According to a contributor further up, smarty is still operating even if set to cache: no, and the error logs from my server do reference Smarty. That said, like with LS Cache (which exacerbates but doesn't create the problem), it may be a red herring. With PHP version ruled out it is hard to say, but there is definitely something in the structure of PS 1.7.6 that is causing some orders to fall over. Perhaps the payment modules do need some work, but the developers seem to think that everything is as it should be in that regard. And the cart mix up/swap over between customers could well be a contributor (or the root cause) if the payment module is unable to update the order - which is what is happening. Going down a rabbit hole of problems that need to be sorted. A display issue here or a goofed module there can be isolated, but if the core function of an eccomerce site (to take a payment and make an order) falls over then there is a fundamental problem that needs urgent address Link to comment Share on other sites More sharing options...
tomerg3 Posted November 2, 2020 Share Posted November 2, 2020 Did you guys try to add some debug code in the Validate() function (it can be as simple as writing tot a log file with "#1", "#2", "#3" text placed in different places in the function, to find out if and where it breaks? Link to comment Share on other sites More sharing options...
Symphony Posted November 4, 2020 Share Posted November 4, 2020 Just an update (and LS Cache workaround tip). Once more, further testing has proved that LS Cache significantly increases the incidence rate of this cart switching / order creation after payment issue - probably because carts are cached. However, we do still get carts switching to a different user with no caches on (Cache/Smarty 'Off' and Litespeed module configured to be off), and I believe this is directly related to failed payments because the payment result cannot find a legitimate cart id to convert to an order. The only way I could operate was to have caches off, and the sort the occasional problem manually. I did find a workaround though suggested by our hosts to allow Litespeed to still run (and thereby make the site run at an accesptable speed) but not cause the problems. By URL blacklisting /cart in the Litespeed module, it doesn't cache that particular aspect, and so therefore doesn't exacerbate the problem and hugely increase the incedence rate of the problem. Definitely something going on though in the background since the 1.7.6.8 upgrade in the fabric of PS. I have asked the payment module developers to make further investigations and debug as suggested - awaiting to hear. Link to comment Share on other sites More sharing options...
tomerg3 Posted November 5, 2020 Share Posted November 5, 2020 "because the payment result cannot find a legitimate cart id to convert to an order." How did you reach this conclusion? Generally, carts are saved in the DB, and once a cart was created, it would not get deleted. It's possible that your cache is causing issues, but the workaround you mentioned should mitigate that (You may want to also include the payment modules' folders). Link to comment Share on other sites More sharing options...
mohamedvasif Posted December 7, 2020 Share Posted December 7, 2020 Hi, i face the same issue. and we have narrowed it down. the issue comes only from chrome browser and the module developer has given the below solution "Please find below soltuion for Chrome null session response issue: The issue where cookies are getting NULL in return journey is occurring with chrome browser 84+ version. There is no restriction from PayU's end as such for cookies . Solution Suggested:The chrome 84 security update says that SameSite attribute of cookie will be Lax(allowed for GET requests) by default and if we want cookie to travel then it should be marked SameSite : None and "Secure" explicitly. (Ref. https://web.dev/samesite-cookies-explained/" Can anyone tell me how to apply this fix. Thanks Link to comment Share on other sites More sharing options...
TigranHak Posted December 18, 2020 Share Posted December 18, 2020 On 12/7/2020 at 3:38 PM, mohamedvasif said: Hi, i face the same issue. and we have narrowed it down. the issue comes only from chrome browser and the module developer has given the below solution "Please find below soltuion for Chrome null session response issue: The issue where cookies are getting NULL in return journey is occurring with chrome browser 84+ version. There is no restriction from PayU's end as such for cookies . Solution Suggested:The chrome 84 security update says that SameSite attribute of cookie will be Lax(allowed for GET requests) by default and if we want cookie to travel then it should be marked SameSite : None and "Secure" explicitly. (Ref. https://web.dev/samesite-cookies-explained/" Can anyone tell me how to apply this fix. Thanks We have the exact same problem and we have been informed from one of our partners, that it is due to Chrome Security Update on version > 84 Has anybody managed to solve this? Link to comment Share on other sites More sharing options...
TigranHak Posted December 18, 2020 Share Posted December 18, 2020 (edited) On 12/7/2020 at 3:38 PM, mohamedvasif said: Hi, i face the same issue. and we have narrowed it down. the issue comes only from chrome browser and the module developer has given the below solution "Please find below soltuion for Chrome null session response issue: The issue where cookies are getting NULL in return journey is occurring with chrome browser 84+ version. There is no restriction from PayU's end as such for cookies . Solution Suggested:The chrome 84 security update says that SameSite attribute of cookie will be Lax(allowed for GET requests) by default and if we want cookie to travel then it should be marked SameSite : None and "Secure" explicitly. (Ref. https://web.dev/samesite-cookies-explained/" Can anyone tell me how to apply this fix. Thanks We have the exact same problem and we have been informed from one of our partners, that it is due to Chrome Security Update on version > 84 Has anybody managed to solve this? Update: I managed to solve this following some suggestions in this topic: specifically the part of code that you need to put in the .htaccess file Presta 1.7.3.3 here. Edited December 18, 2020 by TigranHak (see edit history) Link to comment Share on other sites More sharing options...
Prem M Posted October 22, 2021 Share Posted October 22, 2021 I had the same issue and almost resolved and tested few live transactions and they are a success. 1. Select only one payment option. 2. disable all cache hope this is useful Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now