 |
UbercartOne cart to rule them all... |
|
| Donate | Affiliates | Sponsors | ||
PayPal payments stuck in pending (5.x-1.0-rc5)
Submitted by castellan@drupal.org on Sun, 06/01/2008 - 09:46
I've seen numerous other posts regarding this issue, and it seems to be biting me, now. I'm using 5.x-1.0-rc5 right now and all payments are stuck in pending. I've tried changing/resetting the provided workflow, but nothing is clearing the "pending" status. Any ideas?
Further info: I'm using PayPal Website Payments Pro with PayPal Express Checkout, and I'm assigning a role and creating user accounts for anonymous users. When I check the /admin/store/orders page, all orders show a balance (no order totals have been reduced to 0 dollars). I'm seeing the same issue. Orders are getting processed by the paypal sandbox. In the logs I can see an IPN message with the correct amount. But the balance of the order doesn't get updated. I am also using 5.x-1.0-rc5. I've attached a copy of one of the IPN messages from the log. Any ideas of what I need to change? Thanks for the help in advanced.
IIRC, the provided workflow checks for "when a user completes checkout." This doesn't work for most PayPal orders because there is a slight delay of the IPN coming into the system. You need to create a new workflow that: Occurs when a Payment is entered for an order. I have this setup on our site and it works. Nope, doesn't work on our site. Our order balance is not being updated, so it looks like the workflow never fires. We have the added issue that IPN isn't working, either. We're receiving tons of "Receiving IPN at URL for order 0." watchdog entries. (I've tried turning IPN on, but leaving the URL blank, turning IPN off, turning IPN on and providing a URL. All a bust.) Any other ideas? Thanks for the help! As far as I can tell, a payment is never entered for the order. This is despite an IPN message showing up in the log. What module is responsible for processing the IPN messages? Is there a paypal setting that we might be missing? Or was there a code change in rc5 release? Yes, I think we're having a similar problem, there. As far as UC is concerned, no payment is ever made. Interesting that the IPN is coming in for user 0. Are you making these purchases as Anonymous customers, or are you logged in when you make the order? Actually, it's for "order 0" instead of "user 0," but I am conducting the transaction as an anonymous user. This is for a membership site, and signup creates the user and a specific role. Looks like this guy is also having the same issue: http://www.ubercart.org/forum/bug_reports/4969/installation_error_paypal... I was able to reproduce this issue on the demo.ubercart.org site. I used the "PayPal Website Payments Standard" payment method and the "PayPal Website Payments Pro" payment gateway. Everything else was disabled. Both used the sandbox API server and the gateway was pointed to my sandbox account. I got the same error where the status is left at pending and the balance does not get updated. I wasn't able to check, but I'm guessing the IPN was received successfully, but nothing was done with it.
PayPal Payments Pro (WPP) has nothing to do with Website Payments Standard (WPS). In fact I think you actually need to disable Pro if you are using Standard, and vice-versa (but I could be mistaken). Not sure if this has anything to do with it, but you might give that a shot. I actually have the Pro payment method disabled, and in my Payment Settings > Payment methods screen, PayPal Standard is listed with no gateway attached. I have that as well as authorize.net enabled, but that's all. Like I said, not sure if you need to disable one to use the other... worth a shot, perhaps? BTW I have not upgraded to RC5 yet - is this an issue that just started happening since the upgrade? I tried disabling WPP gateway, and still got the same issue. RC5 is the only version of Ubercart that I've tried. But at least two other people seem to be having the same issue with RC5. Is it worth trying to go back to RC4? How would I go about doing this? Thanks. That is interesting... I guess I'm glad I haven't updated to RC5 yet. Something like this would hose about 40% of our orders, although I would just take out the PayPal method if this turned out to be a real issue, which seems to be the case. So here's what we know so far. Workflow is configured correctly. Hmm. Obviously I think the order# being 0 is the issue, but I'm not sure what would have changed to cause that, since I haven't been able to keep up with the most recent updates. I'm not seeing the "order 0" issue. You can see a copy of my IPN log toward the begining of the thread. I agree. The "order #0" thing may not be the root cause. It's definitely zapping me, but not muenzer. I don't have any experience with the Ubercart modules, so I'm nervous about mucking around until I have some time to sit down and do some evaluation. muenzer, I don't think that's a good idea. If you're using the Paypal Sandbox environment, you might want to check this thread. It sounds like there was a sandbox update around May 28th - same date I started having problems with my transactions clearing... http://www.paypaldeveloper.com/pdn/board/message?board.id=sandbox&thread... Would this issue account for the fact that the Workflow isn't firing because Ubercart thinks no payment has been made? I'm trying to get a better understanding of how Ubercart works. It makes sense that the module might wait until it's received confirmation from PayPal to register the payment. Thanks so much for the link, zsiswick. Just to clear up any confusion, there have been no significant changes to the PayPal IPN code in Ubercart for some time now. The problems people are experiencing are most likely a result of a recent Sandbox upgrade by PayPal. This "upgrade" breaks IPN validation, at least for the code in use in Ubercart. I tried one recommendation in the thread linked above to no avail. Ubercart validates IPNs so malicious users can't spoof the system and get their orders for free. As such, there is no bug at play here in Ubercart. At worst, our code is outdated and we'll have to figure out what to do. At best, PayPal will fix this problem before it causes more consternation. At least it happened before I could put up a 1.0 release. In any event, I don't think there needs to be any more speculation about the problem. I think tP's suggestion for handling delayed IPNs is still solid, the problem is just that payments aren't being entered for IPNs that can't be validated. So... sit tight and I'll let everyone know when this is resolved. As far as I know, this should only be affecting Sandbox users and not live PayPal accounts. I can't verify that, though, so if anyone's live site starts screwing up feel free to post here. Thank you Ryan, I figured I shouldn't worry about it until I've tested it on a live account, especially after I found that thread! Looks like it has to do with validating the IPN against port 443 instead of 80.. (SSL versus normal HTTP). From one of the users on the Developer forum: becomes: $fp = fsockopen ('ssl://www.sandbox.paypal.com', 443, $errno, $errstr, 30); (Note, that's not Drupal code, some other IPN handler.) I will leave it to you guys, I should've asked if it was a Sandbox related issue. PayPal always finds new ways to screw with people... Yep, there's a lot of activity in their IPN forum on this issue. A quick read through there will make you as frustrated as anyone else reporting the issue... PayPal screwed up and doesn't seem to be giving straight answers. In any event, I found a workaround, but I'm hesitant to commit it in case they resolve the issue on their end... if it even is an issue on their end. If the docs weren't so confusing, it would be easier for me to tell. You can comment out line 605 in uc_paypal.module and change line 609 to: <?php(Doublecheck those line numbers... the first should be adding Host:... to $header, and the second should be another fsockopen.) With this, I was able to validate an IPN, but I don't know how universal that is. I believe it requires openssl compiled into PHP, and I'm not sure if the existing code did. If not, I don't want to make it a requirement all of a sudden. Is the ssl:// protocol what makes it require OpenSSL? I always thought that, as long as you specified Port 443, the system would know how to handle it? Interesting.. That change fixed the issue on my end. Balances are now being updated and I also see a log entry for "IPN transaction verified," which was not there before Any idea why the "IPN failed with HTTP error" never got fired. That would have made debugging this issue a lot more straight forward. Here's the code snipped from uc_paypal.module <?phpSeems that $fp gets set no matter what... maybe instead of checking against that variable it should check for $errstr, which, if exists means there was an issue. At least that's how I'm reading that bit of code. I'm not that familiar with fsockopen(), and I'm not sure what message PayPal was sending back... but it seems like it was still getting set, and that's why the IPN validations were getting set for order 0. <?phpI switched to the live PayPal servers and continue to get the "Receiving IPN at URL for order 0." notification. I'm also now receiving the "IPN failed with HTTP error." notification. Pending status is not fixed Did you make the change to the PayPal code as Ryan outlined above? I did not, but it seemed that he was indicating that it would only work for sandbox and not live PayPal. I switched to live and tried a couple of transactions and didn't get positive results. I'll make the change and try sandbox again. The techs on the PayPal forum indicated that the change should fix the issue on both Live and Sandbox accounts. It seems like it should work, based on that - but keep in mind if they change something back again there's the chance you might be reverting these edits. Just a heads up. I haven't seen a problem yet with our live Paypal WPS setup. Is it safe to say this problem with transaction ids was only with the Paypal sandbox? Just trying to clarify. Ugh... Long day and I've figured out a bunch of issues this evening... Basically, WPS works fine, minus the fact that my role wasn't assigned to the anonymous user once checkout was completed, but that's another issue, and my brain is fried. WPP wasn't working for me because, even though my client had signed up for it, he hadn't gotten it approved and so it wasn't active. So, it's safe to say, I was experiencing the problem in sandbox, but never got far enough to experience it in live. Once we get WPP approved, I'll try again and see how things go. Thanks everyone for your patience and insight. What an awesome community! I haven't seen a problem yet with our live Paypal WPS setup. Is it safe to say this problem with transaction ids was only with the Paypal sandbox? Just trying to clarify.
Unfortunately, I'm just not sure. They don't really specify. As a result, I don't know whether to accommodate their workaround in the code or just leave our code as is and hope they solve their own mistake. This really is unacceptable... Ok, we just ran a test on RC3 against live Paypal WPStanard. The order came back and IPN verified for the correct order number. Status went from In Checkout to Pending. Then the action kicked in and changed it to Payment Received. We haven't seen any issues related to IPN's not coming back correctly as far as I can tell -- knock on wood. Is it possible this issue could be made worse by using the secure server module which has to be setup correctly to send the correct url ping back urls to paypal? If you don't have it just right, it will cause all sorts of things to go haywire. Anyway, off to read the forums and see if I can make sense of it. But don't see any problems on RC3 so far. That doesn't mean there aren't any though. I think you're onto something... I help administer a site that uses PayPal WPS and is on RC 5 and it's validating IPNs just fine. So I'm stuck in the situation of having code that works for live users but breaks for testers. I suppose I won't change the way it works right now... we'll see if PayPal gets their act together. I'll think about a failsafe that will attempt the ssl:// request for sandbox users in the meantime. Castellan: Does WPS work fine without changing your code as Ryan mentioned? I wondering if the initial post request going to a 443 port has something to do with it. On the way back it's trying to get to 443 which might not be a valid port in some setups? Ok, one more thought. I wish they all came at once! Would it make sense to check if the secure_pages module is installed. And if so, make all of the checks use port 443? I think that would be a good system wide practice. Or some variable in ubercart -- is your checkout process secured by ssl? Well, using fsockopen() w/ an ssl:// transport requires you to have openssl in PHP. As far as I know, this isn't required for Secure Pages... that is based on the web server. I implemented a fix for now that tests for the function openssl_open() which will be defined if someone has openssl installed. The new code for the headers and sending the request is as follows: <?phpI'd be interested to get some feedback on this, especially for a live site. This means Sandbox testing will still fail for folks without openssl in PHP, but there's nothing I can do about that. I don't feel like holding up a release any longer over this issue... who knows what PayPal will do to resolve the situation. so the only option to get the ipn to update the status from pending to payment received, is to have open_ssl installed? is this a requirement for a Live paypal account as well? This means Sandbox testing will still fail for folks without openssl in PHP, but there's nothing I can do about that. I don't feel like holding up a release any longer over this issue... who knows what PayPal will do to resolve the situation.
 As of the 1.0 release, it was just the Sandbox. Live sites using PayPal were receiving and validating IPNs just fine.    There are some other modules that implicitly require OpenSSL installed - the UPS module for instance uses drupal_http_request() on an https: URL, and drupal_http_request() requires OpenSSL in order for this to succeed (as mentioned in the code comments in drupal_http_request(), but nowhere in the Drupal dependencies list). If you think Good idea, TR. Gonna bookmark your post, or feel free to start another thread for that as a feature request as it might get lost in this one. Hey guys, Thanks think im having this same issue with sandbox I have Ubercart 1.0 with live PayPal account. The PayPal-payments get stuck in pending state. I can see in the watchdog-table a row with message 'uc_paypal/ipn' and type 'access denied'. I was suspecting that the problem was in Path Access module, which I use to restrict the pages the users can access. And there it was. The ACL didn't include uc_paypal* in the list for anonymous user. When PayPal was sending the IPN request, it got blocked by Path Access. Lesson learned: for PayPal payments to work, 1) access needs to be granted to Übercart from the Internet, and 2)anonymous user needs to be able to access URL uc_paypal* in Drupal. Correct me if I'm wrong. If I'm right this info should be written somewhere so that others wouldn't be hitting the same problem. @dc-bob: that sounds right. There might be other PayPal URLs that need to be available, too, for things like canceled payments and Express Checkout. We've run into similar issues w/ Secure Pages, and I believe torgosPizza has documented those elsewhere. Gonna bookmark this to remind me to consolidate the PayPal documentation. My orders are stuck in pending on live site. NOT SANDBOX The only watchdog report I am getting is Encryption failed. Paypal wpp processing ok on live site, Still getting the encryption failed error. Not sure what causing that or how to fix it. Are you running the latest Ubercart? If you're still on RC5, there was one place where I forgot to suppress the error message for missing data for encryption. That's really just a silent warning... what you're really looking for is whether or not uc_paypal in your watchdog is receiving and validating IPNs. Thanks for the reply Ryan. I'm on RC4. And yes watchdog is receiving and validating IPNs, and orders are processing. Alrighty. Updating to 1.0 would take care of the remaining encryption message, and if you go to your Workflow-ng configurations overview, you should be able to enable a configuration that will update orders to payment received when a payment gets entered for an order. I failed to see earlier that you're talking about WPP and not WPS. My orders are remaining in a pending state after i do a full payment at Paypal. The orders are not shipped an are so indicated in the setup. I have read through these posts and made some adjustments to my site. My site is hosted at godaddy and I have adjusted the uc_paypal module to use Curl for the Paypal IPN verification step. This as recommended in another thread on this site. The change solved my problem with the IPN verification, but I still have the Order in Pending state: I have down loaded and installed the latest uc module ubercart-5.x-1.0.tar.gz. Does this include the code to solve the Order pending issue caused by the race condition? How do I resolve this? The logs on my order are as follows: Time User Changes * Added $21.60 for Maryland Sales Tax. 07/21/2008 1 * Checkout message sent to xxxxxxxxxxxxxxx. 07/21/2008 1 * Order status changed from in_checkout to pending. 07/21/2008 - * PayPal payment for $381.60 entered by -. uc_paypal 07/21/2008 - 13:45 IPN transaction verified. Anonymous Array Anonymous
|
|
Notice I took out the :80 from the Host line in the headers... as best as I could tell, this is optional in HTTP/1.x. I imagine it would biff if I tried to specify port 80 there and 443 in the fsockopen(), so I just removed it.
Joined: 06/01/2008