Order status never gets further then 'pending'

I don't think that any mail error will break the payment workflow, but maybe? You could try turning off the 'notification' Conditional Actions and see if it works, but like I said, I don't see how that would be breakin' payment.

yeah thats what I was thinking, but on the CA page I did see that emails are also triggers, at least that what it seems to be saying:

"Trigger: E-mail for granted files".

Yeah... that is its own trigger. You'll see also that there are separate triggers for the actual file renewing though, so one not working shouldn't affect any others...

I have this problem too, only it does not seem to correlate with any mail problem. It appears to be nondeterministic, or at least difficult to predict. It seemed for a while to correlate with the number of items in my cart. I combed through workflow_ng for several hours, and eventually found that _workflow_ng_element_defaults was not getting applied to the uc_order_action_update_status element with payment_received as its status, so it was never actually executed by workflow_ng_execute_action. I didn't get further than this because the problem stopped happening seemingly on its own, though I suppose it could start again. I am using 5.x-1.0.

@frishsticks - you're on an outdated minor version of the previous major version of UC. This one is related to Ubercart on Drupal 6.

I'm going to won't fix this for now, since we didn't hear back from the OP and are not experiencing this bug ourselves.

In my test site, order status does not get updated and conditional actions do not get fired. I downloaded the latest dev of ubercart today - no improvement.

I configured ubercart about a month ago and was not able to get conditional actions to update the order status. I stopped working on the problem (after a week of troubleshooting) in hopes of having this issue fixed in the latest dev. I have worked with the default conditional actions and tested my own. I can manually change the order status to "payment received." But, the order status never gets automatically updated.

I need to start troubleshooting from scratch since it has been about a month since I've worked with ubercart. As of this week, getting ubercart to work is now at the top of my to do list.

What troubleshooting steps do you recommend?

What information would you need to see if this is priority issue for you?

I have
drupal 6 (july 2009 version)
august dev of ubercart 2

Vitis

subscribing, same problem.

Since we're not really sure there's a bug here, this one should be worked out in the support forums. It's likely a configuration issue of some sort, as a majority of users are not reporting a problem (myself included).

Could you clarify which support forum?

Also, I just recently installed Ubercart and this is my first experience with it, so all the settings should be the default from the install, except for adding the extra roles to the sale.

Ahh, sorry - meant the UC forums at http://www.ubercart.org/forum. The quick diagnostic is... are you actually accepting payments? If not, orders should remain in Pending after checkout.

subscribing, same problem

@rszrama
Thanks for the forum link. I had searched that forum for the same issue with no luck resolving it. And no, I'm only accepting payments through Paypal sandbox, not actual payments. In Paypal Sandbox they are showing as posting correctly, but Ubercart isn't advancing the checkout status. I'm hesitant to go live with actual payments for fear this issue will continue.

Subscribing

rszrama said in #10

Ahh, sorry - meant the UC forums at http://www.ubercart.org/forum. The quick diagnostic is... are you actually accepting payments? If not, orders should remain in Pending after checkout.

I have accepted payments in paypal sanbox using ubercart. Since "Paypal Pending" never advanced, I manually changed the order status to "Payment Received." Still, status did not advance to "Complete." I worked with conditional actions - still no movement.

I have posted this in ubercart forums, but no reply.

Because of this issue, I unistalled ubercart and switched to lm_paypal. lm_paypal works beautifully for my needs. But, when customers get sent to the Paypal site (yes, the live site, not sandbox) for processing, the checkout experience is confusing to the point that I think many would give up. So, I'd like to return to ubercart and work with authorize.net or just credit cards - but only if it will work - and I am stumped on this issue.

This issue is a dealbreaker - please help.

vitis

@vitis: Pending is much different than PayPal Pending. You need to adjust your PayPal settings to capture payments instead of just authorizing them.

I believe my issue with order status not advancing is not related to "PayPal Pending."

To test out the functionality of ubercart, I manually updated orders that were stuck in "Pending" to "Payment Received." Still, orders did not proceed to "Completed." I think I have an ubercart problem, since orders do not proceed from "Payment Received" to "Completed."

Am I missing something?

Under what conditions are conditional actions triggered? (Yes, I have tested having conditional actions in the default state, editing existing actions, and made my own) Does the customer need to be online and processing the order for conditional actions to work? Does simply having the order go through paypal affect conditional actions after they have reached "received?"

Conditional Actions respond to events. If a payment gets logged for an order, it will act on that and update the status to Payment received. If an order is paid in full and doesn't need to be shipped, it will update the status to Completed. Whether this happens by the user's direct action or PayPal reporting a payment is inconsequential. However, simply updating the status yourself will have no effect on payment status.

Won't my manual update trigger a conditional action?

i.e. CA says to update order to completed if order = payment received

Nope, look at the conditions. It's actually checking the order balance, not the status.

The order balance is zero.

Will a manual status update (to received) when the balance is 0 and the product is not shippable trigger a status update (to complete)? i.e. all of the conditions are now true.

I would be embarrassed, but happy, to know that ubercart really is working, but my testing strategy is defective.

I'm following this conversation intently, because I'm getting the same "problems" in testing with paypal sandbox and am reluctant to go live with my site currently.

Subscribing, same problem

I'm having the same problem. If you take a look at the users that have already reported the same issue there is OBVIOUSLY SOMETHING WRONG with the PayPal module. It is not very good for Ubercart's reputation if nobody helps us with this matter. Payment is a crucial functionality and not a nice-to-have feature of an online shopping system.

I've already posted my problem along with a detailled description to Ubercart's forum (http://www.ubercart.org/forum/support/13256/paypal_status_pending_order_...) but have not received any answer yet.

Thanks in advance

OK, I had the exact same experience with this, and it has to do with the isolated nature of the sandbox experience.

To use the paypal sandbox you MUST use SANDBOX addresses for both the buyer and the seller. This means you must not only switch to sandbox mode, you must also change the selller address in admin/store/settings/payment/edit/methods to one of the seller addresses in your Paypal sandbox. If you don't have one, you need to generate one.

After much pain, when I used a sandbox seller AND a sandbox buyer, the orders went through.

Assuming that this is the issue for the others, I'm going to set this to fixed. If you disagree, you can reopen it.

I disagree and re-open this issue !

I am experiencing the same problem !
I checked both Drupal'Ubercart issue page, Ubercart' forum and I still not found any answer.

Testing is done under PayPal sandbox with both specific sandbox buyer and seller.

Examining the report : for each test done I have 2 lines corresponding

1. Réception de l'IPN à l'URL pour la commande 18.
2. IPN failed with HTTP error , code 0.

The first one is OK : receive IPN à URL for order XXX.
The second's NOT OK : IPN failed with HTTP error , code 0

I've search both Drupal'Ubercart issue page and Ubercart' forum with this string : IPN failed with HTTP error , code 0

I've started search on Paypal site : did not find usefull answer.

Oups !
I previously forgot to re-open it !

Sorry, I didn't see this ticket previously. I'm experiencing this issue as well, and commented about it in the Ubercart forum.

Following-up to that comment, you can investigate failed IPN requests by logging into your PayPal account, and going to History -> IPN History.

All of my IPN requests are reported as "Sent", meaning that an HTTP response code of 200 was returned when the request to "uc_paypal/ipn" was made, but I know that not all were completely successful. See the PayPal documentation on IPN operations for details on how PayPal interprets the response codes.

The implementation of uc_paypal_ipn() needs to be modified to sent a more accurate HTTP response in cases of verification failure and other errors. The PayPal documentation suggests—but doesn't say explicitly—that the request will be retried up to 15 times: "Retrying indicates that message was resent between 1 and 15 times and PayPal continues to be resend the message". I think a 503 is probably the most accurate code to use.

BTW, this bug applies to the drupal5 branch of Ubercart, which is what I'm running—5.x-1.7 to be exact.

Dan

The ad-hoc HTTP response parsing in the drupal5 branch is all mussed up. It parses and interprets every line of the IPN-verification response as a possible VERIFIED/INVALID PayPal message, headers and all. I'm going to fix this as well—it looks like the drupal6 branch uses drupal_http_request(), so I'll just backport that implementation.

I hope to have a patch available for review some time tomorrow.

Ok, Ive battled with this for at least a week and a half! So... I have read almost every page on the internet (damn near) regarding this issue on ubercart and paypal dating back to last year sometime. The problem is within the "seller" site email address vs. the sandbox "seller" site email address.
- Please see this post above:
http://drupal.org/node/372272#comment-2152828 - rfay hit it on the head.
The problem I think (in my case and in most others) is that initially, when you enable your modules, set up your store, etc. is that most everyone is "happy go lucky" (like me) and put in their REAL paypal email address within their store settings under ubercart. This is a major conflict with the way that the conditional actions fire... Well, they (the ones we need) just wont fire. You NEED to set your installed UBERCART sanbox testing account email to match that of the one within the paypal sandbox seller account, or vise versa.
Initially, I created a "Preconfigured" testing account and never even paid attention to the email that paypal assigned to it, other than to say.. hmmm, lookit that email, so there was my problem all along!
-I set the emails to match and walla, magic happened.
So for everyone that is frustrated and at a loss on this issue, I hope this helps.. thanks to Randy.

@ Ryan and the other developers on this project, thank you for setting up this wonderful piece of code. Without ubercart, there just isnt many other options! Thanks guys.

-P.S. Ubercart and Commerceguys, you might want to post this tidbit of information somewhere in your documentation for ppl like me (hehe). I read this exact page several times until randy's post "hit me" tonight.

One more thing.. I had no problem at all with any default settings that were enabled "out of the box". They all worked great.

More configuration data :

• Drupal 6.14
• Ubercart is 6.x-2.0-rc7

I've just notice an Ubercart update : 6.x-2.0 (2009-oct.-21)

@nurrad
For me installed UBERCART sandbox testing account email match the one within the paypal sandbox seller account.
So problem seems to be elsewhere.
I plan to spend the week end on it !

The problem is within the "seller" site email address vs. the sandbox "seller" site email address.

@nurrad

This isn't our problem either. We've been live for two months and using the live account at the time this happens.

There is definitely a problem in the IPN request handling—just look at the code. At no point and upon no error condition does it send a custom HTTP response, and so it will always be 200. PayPal will assume—rightly so—that the request is successful—even if it's not—and set the value of the IPN request to "Sent". That's what our PayPal IPN History tells us anyway.

Still working on that patch...

Anyone who is consistently getting IPN failures while using the SandBox should also check their uc_paypal_wpp_server and uc_paypal_wps_server settings. I found this wonky logic in uc_paypal_ipn() for deciding against which PayPal server the IPN verification should be made.

So if your WPP settings (uc_paypal_wpp_server ) are set to Live IPN verification will also be made against the live server, even if your WPS settings (uc_paypal_wps_server) are set to SandBox and it's a WPS IPN request.

I was consistently getting IPN failures when testing my patch against the SandBox—my WPP settings were set to Live even though WPP isn't even enabled on my system.

I've changed the condition to this:

I've attached patches for both the drupal5 (Ubercart 1.x) and drupal6 (Ubercart 2.x) branches, against bazaar revisions 1437 and 2001 respectively. There are a couple of important things to note about my changes.

1. I haven't tested the patch for the drupal6 branch (2.x) at all. It's simply a port of the drupal5 (1.x) patch.
2. The drupal5 patch is rather large because the implementation for the IPN verification request was modified to use drupal_http_request() instead of an ad-hoc socket read/write. This modification is basically just a backport from the implementation in the drupal6 branch. It's big because indenting was changed.
3. I fixed a minor watchdog call. The t() call was previously forgotten.

I think that's it. We'll be doing some final testing and deployment of the drupal5 patch tomorrow, so some live testing will be done on it.

Brilliant! I look forward to hearing how it works for you.

OK, I will have a look at this patch this week end… if I solve problems with IE7 rendering on my website ;-)

A few code-style reviews:

This should be "default:".

Drupal 6 watchdog() calls do not use t(), but have separate $message and $variables parameters.

This review is powered by Dreditor.

Done and done. I've fixed the "default" statement in the drupal5 as well, but left the usage of t() with watchdog() as is correct in Drupal 5.x.

Also, since deploying the changeset there have been 145 orders completed with PayPal payment in our store. There are none with pending status, and all with payment_received or completed status have corresponding PayPal Transaction IDs in uc_payment_paypal_ipn with status "Completed".

Hi !

This still not work for me. I give a try on a real Paypal transaction to check whether or not Sandox was guilty. And the answer is : sandbox is innocent.

I add watchdog on payment/uc_paypal/uc_paypal.pages.inc just after the request to Paypal.

And here follow the response :

stdClass Object
(
[code] => 0
[error] =>
)

Everything seems to be OK for the parts involved in the procedure :

• Seller have is money
• Paypal have is commission
• Buyer have a few money in his pocket !

Order status is : In checkout

Do I miss something ?
Does the rules are different for Paypal France ?

I am having this same problem. I am attempting to set up a file download based store, but so far, while in the sandbox, my orders get to the pending stage, and then just stay there. The test 'customer' gets the order number, the e-mail, and the invoice, but not the download. The user profile shows no file downloads, and an order that is still in pending mode. I have tried to adjust everything as this thread seems to indicate, but there is still no improvement. I am not sure where to go next with this problem.

I tested a transaction outside of the sandbox and the same problem occurred.

The ubercart documentation 'selling files' sure makes all of this sound easy, but I guess that was the olden days. Any help is greatly appreciated.

I am running Drupal 6 with Ubercart 2 - all very recent. I am also using the seller and buyer profiles provided by paypal sandbox.

the end result of my test checkout is this page:

Order complete
Operating in off-line mode.
Your order is complete! Your order number is 21.

...and that's it.

Thanks so much in advance - I know that I must be overlooking something somewhere. I know Ubercart is a great module and it is working for tons of people.

subscribing

Hi Markmck1
The 'Operating in off-line mode.' in your status messages indicates you have your site in maintenance mode.
Paypal notifies your site of success by navigating to a certain url within your site.
When your site is in maintenance mode, Drupal will not allow paypal to navigate to this url - it will redirect to the site-offline message.
Hope this helps

subscribing

With my site in online mode (not maintenance) I am getting sandbox to successfully move the order status to payment received. However, the trigger never activates to move the order to completed and grant permissions. Is there any progress on this so an order can go through automatically and grant permission? I've been waiting for months to activate my site and this has been holding me up.

I give it up and use only Paypal checkout : it works fine now !
Furthermore there is a link on the Paypal page to customer who want to pay with credit card.
Ok it's not a direct way to access credit card paiement but it works !

And now the customer I am working for is happy because it's shop have both "Paypal account owner" and "Credit Card" paiements.

markmck1: Are you using a logged-in customer or an anonymous? The only time I've ever seen the event trigger not fire was when the user was anonymous, although this has hopefully been fixed in the latest version of UC2.x.

As for me all the tries were done using Anonymous user.