Jump to content

Orders not appearing in back office, Successful Payment in Paypal


takide

Recommended Posts

Hello!

 

My issue is that orders are not being created in Prestashop, even though the payments are being processed through Paypal just fine. As a result, I cannot view the orders in the Prestashop BO, and my customer's cart is not being emptied after their purchase. 

 

I am running Prestashop version 1.6.0.9. My server is being hosted by GoDaddy on a linux server. I am also using the Paypal USA & Canada Module (1.3.9)

 

Here is a list of things I have tried so far:

-- I have scoured the Prestashop forums and have found a couple threads with my similar issue. However, none of them actually come to a solution.

-- I have completely removed the module and reinstalled it several times with no progress.

-- I have double checked the data that I have entered for my Paypal account and my Paypal API credentials.

-- I have tried debugging the Paypal module ("validation.php" file). From what I have tried, around line 77, the "response" variable is null. I have tried commenting out the "if response='verified'" statement but orders are still not being created in the Prestashop back office. 

-- I have taken a look at the Paypal IPN logs, and it appears that they are being sent to the validation.php file on my website just fine.  

 

Has anyone else had this issue? What else can I try? I have fairly good PHP experience, but I am confused why orders are not being created even after the "if verified" statement is commented out and overridden. I am using the Paypal standard payments option, so I believe that the issue must reside within the "_paymentStandard()" function.

 

Thanks in advance for your time and support  

  • Like 1
Link to comment
Share on other sites

Update: It looks like the validation.php file is not being called at all when the user is checking out. I have placed code in the validation.php file to see what parts are being executed and what some variables are. These values are appended to a log file in the Paypal module directory. I double checked my IPN return url in Paypal and it is pointing to the validation.php script. This is really starting to confuse me.....

 

Any suggestions from here? Why would the validation.php file not be called? I also noticed that there is no closing "?>" php brace at the end of the file. Shouldn't it have a closing tag?

Link to comment
Share on other sites

Update: I have been testing my validation.php script to see if it will work with the IPN POST data as seen in the IPN receipt in Paypal. So far this is working. However, in Paypal it appears that the url on the IPN receipt is: mydomain.com/store/modules.paypalusa/validation?pps=1

 

I tried doing the same tests with that URL and it is not working! (Good news, now we at least know what the problem is.)

 

I know that my server sends the validation url to Paypal somehow, so now I just need to find out how to change that url so that it includes the proper .php extension. Does anyone know how to change this?

Link to comment
Share on other sites

  • 3 weeks later...

I am having the same issue (no orders being recorded in back office, PayPal payment records on PayPal), no order emails being sent. Have you found a fix for this problem?

 

I'm also having the same "no order" problem with Authorize.net module, no orders recorded in back office. Using version 1.6.1.2.

Link to comment
Share on other sites

UPDATE: I was finally able to fix this issue by disabling friendly URLs. Its a shame that this module has no mention of its incompatibility with such a simple Prestashop feature. The friendly URL setting must have been chopping off the .php from the validation.php script, making it so that the orders were not being processed.

 

FoodAssets - I could take a look at your site and help you fix your issue if you would like. Double check and make sure that you have friendly URLs disabled. 

Link to comment
Share on other sites

The issue is actually with the Paypalusa module.  The module has a function named getModuleLink, and this function assumes that Friendly URL is always turned on.

 

Since most merchants will want to use Friendly URL, then to fix the issue replace the modules getModuleLink function with the one below.

    public function getModuleLink($module, $controller = 'default', array $params = array(), $ssl = null)
    {
        //bellini: need to append '.php' to the end of the controller for PS v1.4.  Cannot assume Friendly URL is turned on, so either need to add a check, or append .php
        if (version_compare(_PS_VERSION_, '1.5', '<'))
            $link = Tools::getShopDomainSsl(true)._MODULE_DIR_.$module.'/'.$controller.'.php?'.http_build_query($params);
        else
            $link = $this->context->link->getModuleLink($module, $controller, $params, $ssl);
            
        return $link;
    }

And the best thing is that I reported this issue over a year ago to Prestashop github, and they closed it and never addressed the issue

https://github.com/PrestaShop/PrestaShop-modules/pull/415

Edited by bellini13 (see edit history)
  • Like 1
Link to comment
Share on other sites

It's really a shame that you have to manually change the code to get the standard Paypal module to work with Prestashop. It's even more irritating that such  simple fix has not been implemented in the Paypal module. Prestashop and their developers should really step up their game.  :angry:

  • Like 1
Link to comment
Share on other sites

I think the problem is this is a garbage module filled with garbage code. PayPal has never once worked despite intensive labor put forth into it to make it so. Not even in the past with previous versions has it worked, and I have been with PrestaShop for some years now. Every new release fails to fix the functionality of this module. I suspect the real problem here is with developers intentionally releasing garbage so the end user has to purchase "support" to get it fixed.

Edited by FoodAssets (see edit history)
Link to comment
Share on other sites

Okay, tried implementing the code fix above. It still doesn't work. No orders created (except in PayPal), nor is an order generated in Back Office.

Can you code in PHP? Try adding some debugging capabilities to the validation.php file. (Appending variables/ ipn data to a log file, etc). I can still take a look at your code if you would like. I know the Paypal module a little too well now that I have resolved my issue.  <_<

Link to comment
Share on other sites

so why not just move on from the garbage module, and purchase one from an establish module developer.  will be cheaper and less frustrating for you

 

Well, that's the goal, isn't it? Go ahead and release poor code, offer little to no repairs, and create an entire army of thousands of frustrated Prestashop users, all of which have to go find paid support or paid modules?

 

By the way - those are not my words either - they came from a Prestashop support person, the only one I finally found in 4 years of effort and frustration with PayPal (and other Prestashop issues). Don't even get me started on all the hack 'coders' out there that are releasing modules or offering their bastarized version of 'support' - many are well-known right here on this board and they're fucking terrible at their jobs. I'll be firing two seperate firms this week.

 

Prestashop has no incentive to create quality software because they are actually in the business to create a revenue stream for themselves with paid support and paid modules. This is hidden from the new users - who 'invest' significant time and effort into their new websites, only to discover that there is a lot that doesn't work as expected. They hopefully come here for advice on how to solve issues which is contradictory support at best. Users are not ungrateful for the help offered - just frustrated after months of seeking solutions that it's STILL broken. The PayPal module exemplifies this issue in SPADES, but there are others too.

 

There is no incentive under the Prestashpo business model to ensure quality code that actually works as users expect. PayPal has uttely abandoned it's users and in my case, lost millions in sales (for real). I found a way around this piece of shit code in the past by simply forcing the PayPal user to log in and send payment amount directly to the shop. Cludgy, but "bulletproof" (works EVERY time).

 

But I never learn... so I upgraded to a new domain, new version of Prestashop and tried PayPal again. Same problems as before. Same conflicting "solutions". Same non-support from PayPal. It's quite evident to even the most obtuse that resolution on this module will never be made. There are hundreds, if not thousands of complaints here on this module.

 

Those of you that have gotten this to work - kudo's to you. Hope it lasts during your next upgrade. I'll keep trying for the time being because I'm stubborn as hell, but my opinion of this crappy module remains the same as ever, it's a piece of shit.

 

Prestashop has a devloped big bad reputation and it's not improving. It's a user nightmare for those that can't unravel the code and fix it themselves. Nobody is listening, nobody cares. Rants like this just get ignored. The whole business approach by Prestashop is a pretense - it's "open source" and "free" but in reality, not even close. It really needs a strong management team that takes charge and also cleans house amoung the army of module developer (stop releasing crappy modules). A serious quality improvement program needs to be implemented vs worrying about developing the next "upgrade" or new feature.

 

I've bought several paid modules by the way - and for certain, they are not all "good". The same "let's make money" incentive exists amoung module developers, who are scrambling all the time to get their code to work with Prestashop and it's many, many changes. That may be a way to make money - but it's a really poor business model to satisfy the end-user.

 

Many go elsewhere after these 'experiences' and get a different shopping cart - many have posted this right here on this board.

 

Yes - I could buy a paid PayPal module - but hey, I have NO IDEA if it actually works as advertised. I'm gun shy now, having been repeatedly burned by PayPal and other module developers.

 

Not all users are coders - frankly, we should be RUNNING our businesses and not having to worry or tweak the code. Fair warning to any would-be Prestashop users - you really do need quality support personnel or the ability to do it yourself - otherwise forgetabout it and go elsewhere.

 

Rant OFF.

  • Like 1
Link to comment
Share on other sites

Until takide solve the problem, I wrote Paypal who informed me about that problem.

 

 

Merci pour la précision et la rapidité de votre réponse. Suite à vos informations, j'ai effectué plusieurs recherches et Prestashop ne semble pas être intéressé à s'occuper du problème.

 

J'ai donc décidé de reconstruire ma boutique au complet sur Opencart.

 

Je crois que Paypal devrait interdire immédiatement l'utilisation de son nom et de son logo à Prestashop en ce qui concerne leur module Paypal USA-Canada-Mexico. Votre réputation est grandement affectée aux yeux de la clientèle.

 

Je vous souhaite une bonne journée.

 

Jean
Link to comment
Share on other sites

Hi takide. Your right. Do you know how to do ? Because everybody here (exept Prestashop) is searching for a solution.

 

If you got one, don't be shy, please tell us!

 

My issue was that the validation.php file was not being called from the Paypal IPN services. I was able to fix this by disabling friendly URLs. (Although, through my week long debugging experience I learned WAY more than I should have about the module.) Could you please give me some more information about your problem? I do a lot of contract work and could take a look at your site for relatively cheap as well.

Link to comment
Share on other sites

Hi takide,

 

I tried to disable friendly URLs. Still the same problem. Here's a list of all trouble I got. When there is no shipping fees, every thing goes perfect. But :

 

  • When there are shipping fees, the order is not confirme in Prestashop and stays in the cart.
  • Paypal bills taxes on shipping fees even if they are already billed in the cart.
  • When a customer buy as a guest instead of a registred client, there are not even a cart in prestashop after he payed with Paypal.

I you are able to solve all these problems, you'll be considered the king,no, the GOD of this forum !

 

Thanks for helping takide.

Link to comment
Share on other sites

I bet that the order totals from Paypal does not match the order total in Prestashop. I recommend overriding the code that checks if the order total from Paypal equals the order total from Prestashop.

 

If you do not have sufficient PHP skills to debug this issue on your own, I would be able to take a look at your site. I charge very fair rates for my work. You can contact me via my website: (http://thespinoff.biz/store/contact-us)

 

One thing that really helped me was logging information to a file. This way I could see how far the validation.php program was going before it stopped, and I could see the values of other variables and stuff. Here's what I used:

file_put_contents('log.txt', "\n" . $datevar . ' Stuff to log here. variable value:' . $myvar , FILE_APPEND | LOCK_EX);
Link to comment
Share on other sites

Hi all,

 

I have the same problem with Paypal payment but I think my problem is with orders as it seems not working.

verison: 1.6.1.3 (http://eshop.rednerium.com/en/)

 

The final procedure with the paypal payment redirects to a blank page, in some case payment is successful (if you check paypal account - I ve tested it) and in some is not (customers informed me)... because in Back office the "order" (no actually order) is pending in "Shopping Carts" as "Non ordered" (no emails verifications sent etc.).

 

...the second part of the problem (if the payment is successful) is when I go manually to proceed/complete with the order via shopping cart "create an order for this cart" I am getting the following error:

[PrestaShopException]

Can't save Order
at line 345 in file classes/PaymentModule.php

340.                     // Creating order341.                     $result = $order->add();342. 343.                     if (!$result) {344.                         PrestaShopLogger::addLog('PaymentModule::validateOrder - Order cannot be created', 3, null, 'Cart', (int)$id_cart, true);345.                         throw new PrestaShopException('Can\'t save Order');346.                     }347. 348.                     // Amount paid by customer is not the right one -> Status = payment error349.                     // We don't use the following condition to avoid the float precision issues : http://www.php.net/manual/en/language.types.float.php350.                     // if ($order->total_paid != $order->total_paid_real)

..... Is anybody faced the same issue? Is there any solution on this? Can anybody helps to solve this problem?

 

Thank you!

Link to comment
Share on other sites

  • 3 months later...

Hi FoodAssets and everybody!

 

Well, that's the goal, isn't it? Go ahead and release poor code, offer little to no repairs, and create an entire army of thousands of frustrated Prestashop users, all of which have to go find paid support or paid modules?

 

By the way - those are not my words either - they came from a Prestashop support person, the only one I finally found in 4 years of effort and frustration with PayPal (and other Prestashop issues). Don't even get me started on all the hack 'coders' out there that are releasing modules or offering their bastarized version of 'support' - many are well-known right here on this board and they're fucking terrible at their jobs. I'll be firing two seperate firms this week.

 

Prestashop has no incentive to create quality software because they are actually in the business to create a revenue stream for themselves with paid support and paid modules. This is hidden from the new users - who 'invest' significant time and effort into their new websites, only to discover that there is a lot that doesn't work as expected. They hopefully come here for advice on how to solve issues which is contradictory support at best. Users are not ungrateful for the help offered - just frustrated after months of seeking solutions that it's STILL broken. The PayPal module exemplifies this issue in SPADES, but there are others too.

 

There is no incentive under the Prestashpo business model to ensure quality code that actually works as users expect. PayPal has uttely abandoned it's users and in my case, lost millions in sales (for real). I found a way around this piece of shit code in the past by simply forcing the PayPal user to log in and send payment amount directly to the shop. Cludgy, but "bulletproof" (works EVERY time).

 

But I never learn... so I upgraded to a new domain, new version of Prestashop and tried PayPal again. Same problems as before. Same conflicting "solutions". Same non-support from PayPal. It's quite evident to even the most obtuse that resolution on this module will never be made. There are hundreds, if not thousands of complaints here on this module.

 

Those of you that have gotten this to work - kudo's to you. Hope it lasts during your next upgrade. I'll keep trying for the time being because I'm stubborn as hell, but my opinion of this crappy module remains the same as ever, it's a piece of shit.

 

Prestashop has a devloped big bad reputation and it's not improving. It's a user nightmare for those that can't unravel the code and fix it themselves. Nobody is listening, nobody cares. Rants like this just get ignored. The whole business approach by Prestashop is a pretense - it's "open source" and "free" but in reality, not even close. It really needs a strong management team that takes charge and also cleans house amoung the army of module developer (stop releasing crappy modules). A serious quality improvement program needs to be implemented vs worrying about developing the next "upgrade" or new feature.

 

I've bought several paid modules by the way - and for certain, they are not all "good". The same "let's make money" incentive exists amoung module developers, who are scrambling all the time to get their code to work with Prestashop and it's many, many changes. That may be a way to make money - but it's a really poor business model to satisfy the end-user.

 

Many go elsewhere after these 'experiences' and get a different shopping cart - many have posted this right here on this board.

 

Yes - I could buy a paid PayPal module - but hey, I have NO IDEA if it actually works as advertised. I'm gun shy now, having been repeatedly burned by PayPal and other module developers.

 

Not all users are coders - frankly, we should be RUNNING our businesses and not having to worry or tweak the code. Fair warning to any would-be Prestashop users - you really do need quality support personnel or the ability to do it yourself - otherwise forgetabout it and go elsewhere.

 

Rant OFF.

 

This is exactly my experience! I was recommended about Prestashop, bought a template and modules, and have been working for more than 5 months to get my shop opened, as I have no coding skills and ALL THE TIME I'm find new things that do not work or that are not explained well. Very frustrating, but as I already put so much money and time into this, I will try to get  the shop opened and working some time before changing to another paid shopping cart...

 

However, to the Paypal issue: I had the Paypal Usa-Canada module on my shop, but as it didn't transmit the orders to me or the "client" I just changed it to the Paypal Mexico. With this the orders have appeared with automated order messages to the client and does show orders in the dashboard, but now  have the issue that and "old client" does not receive new orders in her "My orders". It shows just the old order, no updates. (These are test orders before opening the shop public).

 

Good luck everybody!

Link to comment
Share on other sites

so why not just move on from the garbage module, and purchase one from an establish module developer.  will be cheaper and less frustrating for you

Because that is EXACTLY what Prestashop developers want Prestashop users to do - to achieve such a high level of frustration that they will be forced to hire a developer to fix the inherent problems and buy support or a module. I have a MAJOR problem with this scam because that is exactly what this is. It's a SCAM orchestrated on the entire Prestashop community.

 

Why should I buy into this scheme? That makes me as complicit as the idiots that wrote this crap. And I won't do that. Since posting this thread, I've had other Prestashop problems and have to fire two developers for more crap coding, leaving my site more broken then before. I wound up fixing all of it myself. So 'hiring a developer' is very iffy. Even the "good ones" will leave you hanging. Never again.

 

And no, PayPal module has NEVER worked.

 

I found a work around - trash the PayPal module altogether and NEVER use it. Simply show the order totals on the checkout page and provide the link for the customer to login to PayPal themselves and send the money to the store. Works every time. No "developer" or paid module needed. No need to worry about whether you hired a competent developer or not. No need to EVER worry about upgrading either, or a module becoming non-supported because you're never going to use it and never going to need it.

 

Prestashop is NOT "free" nor without many headaches (and not recommended except for those that like lots of pain). The "open source solution" simply isn't. Merchants need to get PAID - not PAY to have CRAP fixed on software that is simply unready for the real world of business.

Link to comment
Share on other sites

Can you guys quit complaining? I posted instructions to solve this issue, and anyone with a basic knowledge of computers can do it. While Prestahsops business model is very deceiving, you got exactly what you "paid" for. You buy cheap shit, you get cheap shit. That's the way this works!

 

If anyone would like me to fix this issue for them, I would be happy to do so. Feel free to contact me. I am not the piece of shit developers that the "certified" Prestashop developers are, and my rates are very affordable.

 

But please, quit complaining about "products" you haven't payed for!

  • Like 2
Link to comment
Share on other sites

Yes the Paypal-USA module is not 1.6 compliancy and yes, PrestaShop does not care...

 

Personally, I took time to debug it for my Canadian clients, and I ask $ 10 for the job. It's too expensive ?
Same problem for Desjardins module elsewhere ...
Link to comment
Share on other sites

Well in my opinio if something is free, it might not have many services, but I do not like about the fact that something pretends to be something that isn't so that people who do not understand about these things (like me) will find out it after many months of trying haha :D But world is not like I would like it to be... :)

Link to comment
Share on other sites

 

 

I found a work around - trash the PayPal module altogether and NEVER use it. Simply show the order totals on the checkout page and provide the link for the customer to login to PayPal themselves and send the money to the store. Works every time. No "developer" or paid module needed. No need to worry about whether you hired a competent developer or not. No need to EVER worry about upgrading either, or a module becoming non-supported because you're never going to use it and never going to need it.

 

 

So the clients have to put the charged amount by themselves in the Paypal with the format "send payments" or how does this work? 

I'm not sure if I understood how to do it.. :)

Link to comment
Share on other sites

 

 

I found a work around - trash the PayPal module altogether and NEVER use it. Simply show the order totals on the checkout page and provide the link for the customer to login to PayPal themselves and send the money to the store. Works every time. No "developer" or paid module needed. No need to worry about whether you hired a competent developer or not. No need to EVER worry about upgrading either, or a module becoming non-supported because you're never going to use it and never going to need it.

 

 

 

Sounds like a good way to do it. Would you be able to explain how to do it? I have no coding skills so would be great to get some detailed explanation on how to really do it.. Thanks!

Link to comment
Share on other sites

  • 1 year later...

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...