Signups not created when paypal express, sandbox gateways fail to call hook_order case submit.

Do your orders have a zero payment balance once they are cleared?

I think so. When I go to "View Orders" the status of each is "Payment Received". When I view an individual order, there is a "Payment" block with "Balance: $0.00" in it.

Hmm, if you go to admin/store/ca do you see the uc_signup conditional actions?

I am having the same issue actually. There are two conditional actions for uc_signup.

Payment by cheque works (when the conditional actions are disabled)
Payment by paypal standard payment does not work.

Only difference I can find is the form actions at /cart/checkout/review.
Cheque form action="/cart/checkout/review/"
Paypal form action="https://www.sandbox.paypal.com/cgi-bin/webscr"

Interesting. Thanks for the additional info. Can you both report what kind of database you're using?

I running MAMP, so using mysql. I've also tried it on two fresh installs and neither seems to work with paypal.

I think I've narrowed it down to the submit button at the final stage of checkout. I think because when I used a cheque and click submit order, the follow page processes the order and sends the 'submit' op that fires the switch statement in function uc_signup_order($op, &$arg1, $arg2) {. I also think that because a cheque is 'pending' and not complete, and also has a balance greater than 0, the signup is canceled immediately. I can disable the conditional actions and then paying by check seems to work as expected (the users are signed up, and registered).

Yet, when I click the submit button for a paypal payment, I am redirected to paypal's checkout (as expected) but I don't think uc_signup_order(... is every called, so the signup could never be added.

Is there a way to adjust the conditionals that could account for paypal payments?

same probelm ... on finish order, there is message "Signup to !my_event cancelled."

* bump *

I have the same problem and I really need to solve this, thanks a lot

I marked #528526: When completed the checkout: Signup data (attendees) not inserted into signup_log tables as a duplicate of this.

It seems we need to take another approach for stores where the order balance is not completed during checkout.

What happens if you do all of the following?:

-- disable the "Cancel temporary signups created by UC_Signup upon checkout with a remaining order balance." predicate
-- Create a new predicate with the following parameters:

Trigger: Order status gets updated
Condition: Check the order status.
Argument: Updated order.
Order status: Completed
Actions: Mark temporary signups as paid

I think this might solve the problem. Hopefully on this long list of people with the problem we can get a few testers :D!

In general I think changing the predefined conditional actions that uc_signup provides to be closer to the above would be a good idea.

signup now works ... but immediately - signuped as soon as order of event created and is in pending state :-(
and also there is some more bug - message after FISRT order of event submited [Submit order on Review Order pressed]

* warning: Invalid argument supplied for foreach() in /hosting/halfpixelstudio.com/jesushouse/HalfPixel-JesusHouse/drupal/sites/all/modules/contrib-dev/uc_signup/uc_signup.module on line 596.
* The selected file could not be copied, because no file by that name exists. Please check that you supplied the correct filename.
Signup limit reached for test2uc_signup, signups closed.

In attachment is my setting of CA followed your guide

I used your custom predicate, but wasn't able to to get it to work. Drupal 6 (obviously), PHP 5.2, MYSQL. I've confirmed that the order got set to "completed" and the balance is $0.00, but I didn't get the sign up. I feel like I may have missed something when setting up the module in the first place, though. I have a Product with the signup enabled, as well as the custom rule, and can't get the user to show as signed up after the order is marked completed from PayPal. Thanks for any help.

DOUBLE EDIT:

Scratch all that stuff I said in that first edit, I was just missing something. Back to the fact that I followed the steps I outlined above and am unable to get the user signup to happen.

I think I've found what the issue may be. See: http://drupal.org/node/379724 for an example of another module that had the same issue, but it looks like there still may be some remaining issues with hook_order being called with "submit" as the type, when using PayPal. I've tested and confirmed that it doesn't actually get called when going through the process with PayPal.

Well, I've created these two patches to kind of resolve this issue. They work for me, but they've only been confirmed (confirmed by me alone, which is never a good thing) to work with the Paypal checkout, I have NO idea how they'll integrate with other checkout systems. Basically, as I stated above, the uc_order never gets called correctly for Paypal, so that stunted the module right there. When I got around that thanks to the advice in the link I posted, it seemed that the $_SESSION wasn't getting carried over, I wonder if it had something to do with the whole process of Paypal leaving the site then redirecting back, but I don't know the full details. I know I did use my Paypal account and set the WPS complete URL according to the steps here: http://www.ubercart.org/faq/2439. Please let me know if anyone can try this patch, see if it works, and if there's anything else I can do to help.

I have a client who has this working properly with paypal, so I think this idea about not calling hook_order case submit needs more explanation. Perhaps the paypal integration needs a patch.

The patches you've posted contain debug messages, and replace a ~100 line hunk with another one, so they're hard to review. Could you provide more explanation of the changes you're making here?

For future reference, you can combine patches that describe changes to multiple files into a single patch.

Yeah, but I'm not very bright about that kind of stuff. Frankly, I'm amazed I was even able to make a patch. In fact, looking over it, it looks like I even screwed up that part, and patched the file backwards. I don't see anything about any debug messages, though (just a watchdog message that's more of a warning to inform when it doesn't work). I apologize for any inconvenience, I'm just trying to get this working for myself and posting back my changes to see if it may help any others. Also, this was against the beta3, not the dev version.

In my tests, I wasn't able to get PayPal to call uc_order with "submit", so I do think that this is most likely a problem with UC and Paypal, as opposed to this module. However, modifying this module is a lot less of a beast than modifying UC, so I tried to make this patch. The patch basically rewrites the entire uc_signup_order function to do a few more checks with Paypal. Instead of the "submit", it waits for an "update" with the status of "completed" to do any of the PayPal stuff. Then, it added some extra functionality to push/pull from a new table that just stores a serialized version of the session that contains the keys. I wasn't getting the session back from Paypal, so I created that functionality to store it across the process. I also added that watchdog at the end just to post to the logs about it not working, but there shouldn't be any debug statements in there. I've attached an updated version of the patch, hopefully it'll be a little more accurate. Sorry for any problems, maybe it would be better just to implement this "fix" for myself and not try to hack away at others' code?

Since there are 2 underlying problems in this issue, we should split it into 2. Ive created #560074: Predicates should be more flexible for the changes described in #9 of this issue. I think that the paypal gateway should be fixed to call hook_order with op submit, which is standard, if possible.

Makes sense, and it would be better than the patch I created. Though, what would happen in the original module if an administrator marked an order as "complete"? Would the predicate take care of the assignment, instead of hook_order (since I don't know if that would call hook_order with the op as "submit")?

Yes, that would work properly because the user would have submitted the order when it was originally placed.

Hi. Just wondering if there are any updates on this issue. I'm using the beta4 version and I still can't seem to get signups created when using paypal.

Confirming. As of now, Paypal Standard completes order/payment, however signup is not processed.

Yes, same results for me using PayPal sandbox (no updating of signup list after checkout). I am using Ubercart 2.0 rc7 (not 2.0 because of problems with the date module), Drupal 6.14 with MySQL, uc_signup 1.0beta 4 (and tried 1.x-dev of Sep. 29 with same result), Signup v1.0 rc6.

Another point along these lines...
I get two buttons when I have the signup and uc_signup modules active. First of all, I get a button for the signup module (by default it says "Sign up" and is visible from the Signup module (even when Ubercart or uc_signup is not present). When uc_signup is enabled, then it adds another button below it (I believe that the default is "Signup for course". If I click the first button, then I am signed up for the event, but do not have to pay. If I click the second button (i.e., "Signup for course"), then I can step through the PayPal payment process with no problems, but after it is all said and done, no-one gets added as being signed up. The order can be seen, however, in the list of product orders. I am assuming that we no longer need to patch the signup module. Is that correct?

i 100% agree with #22. the payment goes in fine, but after that proper signup registration is MISSING:
1) it need to register the paid user onto the signup event the user paid for.
2) on the signup page itself, it should not have 2 buttons- one for "add to cart" (to pay for this event), one for signup. I can disable "signup" for this paid event, but if i do, all configuration (signup limit, all emails for this event) won't work, as well as i cannot manage the signups via singup configuration.
any thoughts? i have this pressing issue to make this site live with this module... we're really close... so any help + advise will be GREATLY and sweetly appreciated!!! :-)

Please see the README, which says that paying users must not have the "sign up for content" permission otherwise they will be able to sign up for free (and see two buttons on the signup screen).

I believe the problem with signups not being created still has to do with this payment gateway not calling hook_submit as described in #13. It would be great if someone affected by this issue could investigate it with the paypal gateway.

@rob_feature: uc_signup works with paypal standard. Please try reproducing this problem on a fresh install with your payment gateway and let us know how it goes.

I believe the problem is with paypal sandbox and paypal express. Can others on this thread confirm that this is the payment gateway they're using? Since we've identified the source of the problem (see #13), I'm marking as active.

I would love to pursue this for users who are having problems with the other gateways but at this point I think the best solution is to hire a developer to work on the paypal gateway or/and uc_signup if you need to use those gateways.

I as well have signups that are not counted using paypal standard. The order is changed from a status of "in checkout" to a "completed" status at the moment I click "pay now" in paypal, however no signup is added. Signup is working fine with checks.

Just tried out a new fresh install with paypal standard and it still does not seem to count the signup. Like tylerz, checks seem to be processed alright.

I was experiencing this same issue.

I wanted some clarification: is this just for the sandbox? does that mean that on a real account with the live gateway the expectation is that it works?

I just tested the live gateway and that seems to have the same problem - so it's not just the sandbox, its paypal standard live and sandbox.

what i see is that for all paypal gateways, there is no temporary signup being created.

i suspect that is why nothing changes when the transaction is complete.

I'm also experiencing this problem. I'm using Paypal Standard Live. Happy to test a fix if someone wants to suggest something?

I wonder if we could simply add a module_invoke_all for hook_order somewhere in the paypal gateway, and how this would affect other modules.