Signups not created when off-site payment methods fail to call hook_order case submit.

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

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.

I was able to take a moment and look at the paypal gateway. I haven't tested this but a fix here that would also help other modules that depend on hook_order would be to patch uc_paypal.module to add the following at the top of uc_paypal_ec_submit_form_submit() after the order object is loaded. I'd like to test and file a patch and new issue with Ubercart if this fix works and seems appropriate after testing.

  foreach (module_implements('order') as $module) {
    $result = module_invoke($module, 'order', 'submit', $order, NULL);

    $msg_type = 'status';
    if ($result[0]['pass'] === FALSE) {
      $error = TRUE;
      $msg_type = 'error';
    }
    if (!empty($result[0]['message'])) {
      drupal_set_message($result[0]['message'], $msg_type);
    }
    if ($error) {
      $_SESSION['do_review'] = TRUE;
      drupal_goto('cart/checkout/review');
    }
  }

subscribing

Subscribing

Subscribing

i tested the patch in #33 and it seems to work. (i just tested it once with the sandbox).

hope that will encourage others to test and get the ball rolling.

any hints on what to look for i'm wanting to use this on a production site?

sorry, i was wrong, it doesn't seem to work after all. the signups aren't being created at any point in the process.

i found another problem. (maybe related to this? if not move to separate issue):

there seems to be something wrong with the actions.

on /admin/store/ca/uc_signup_cancel_signups/edit/conditions or /admin/store/ca/uc_signup_mark_paid/edit

if you click on the conditions tab you get the error:

* warning: array_keys() [function.array-keys]: The first argument should be an array in /sites/all/modules/ubercart/ca/ca.admin.inc on line 598.
* warning: array_shift() [function.array-shift]: The argument should be an array in /sites/all/modules/ubercart/ca/ca.admin.inc on line 598.

i deleted them and recreated them by hand from the info in the module. but it didn't fix anything but it did make the error messages go away.

subscribing. I need this functionality for a site that's going live on Monday. If you have some idea of what's causing the issue, I can spend some time trying to fix it tomorrow evening.

any progress on this? anything in the latest dev version that might help?

we're seeing this error, too, and trying to see what suggestions we can dig up on our end (Ezra, we'll let you know what results we see with your code from #33 above).

as a band-aid in the meantime, i just wanted to note a simple hack to manually sign-up users that have purchased sign-ups/registrations: give some privileged user role permission to 'sign up for content', login as a user having that role, be sure the node's signup status is 'open' (node -> Signups tab -> Administer link), and then add the signup via node -> Signups tab -> Add link.

as noted by Ezra above, be sure that the 'sign up for content' permission is not enabled for non-privileged site users who you want to pay for sign-ups/registrations.

Subscribing

I am looking at using these modules and I was wondering if this problem occurs with paypal website pro or express as users are not redirected off the site. Can you use these api's with these modules?

hi there

I am just testing with sandbox. I put the business address into the payment gateway. But I keep getting the error message:

You do not have permissions to make this API call

Secondly, I cannot use the checkout with paypal also as I have this message:

This transaction is invalid. Please return to the recipient's website to complete your transaction using their regular checkout flow.

What did I do wrong ?

Thanks

Al

Subscribing

Subscribing as well. I came into this issue when a client clarified that they were using Payflow Link (and not Payflow Pro) a few days before launch.

My (very ugly) hack has been to add the following lines to the end of uc_payflowlink_form, which is called by uc_payflowlink_form_alter. Other UC Paypal modules have similar implementations of hook_form_alter, which are all basically the root of the problem we're talking about here.

  foreach (module_list() as $module) {
    $function = $module .'_order';
    if (function_exists($function)) {
      // $order must be passed by reference.
      $result = $function('submit', $order, NULL);

      $msg_type = 'status';
      if ($result[0]['pass'] === FALSE) {
        $error = TRUE;
        $msg_type = 'error';
      }
      // Stop invoking the hooks if there was an error.
      if ($error) {
        break;
      }
    }
  }

What this basically does is call all the hook_order functions as if payment had cleared and finalized. The obvious problem here is that the order is confirmed (and the signup added, etc) just before the user is sent offsite to Paypal. If a savvy or negligent user doesn't complete Paypal's payment process, the only way I'll know if by matching up the UC order records.

This band-aid works better for me that #41, since I can sort out the payments afterward rather than having an angry attendee who paid but isn't on the list. But then again, my priorities are skewed because I have a live, broken site on my hands.

Okay, so I got a marginally less ugly fix running that's been successful so far. The basic idea is to add an additional function to serialize the stuff that uc_signup keeps in $_SESSION and drop it into a new database table created for this purpose.

function uc_signup_preorder ($op, &$arg1, $arg2) {
switch ($op) {
    case 'submit':
  //serialize the data and store it
  $query = "INSERT INTO {uc_signup_payflowlink_log} (order_id, signup_data) VALUES (%d, '%s')";
  db_query($query, $arg1->order_id, serialize($_SESSION['uc_signup']));
  }
}

From there, one needs to modify uc_signup_order to query, unserialize and use this info instead of $_SESSION. You would also need to add a call to uc_signup_order somewhere in the function that processes posts from paypal so that it knows to run the function and complete the signup. For uc_payflowlink, I added it right below the 'if ($_POST['RESULT'] == 0)' in uc_payflowlink_response.

So, apart from mangling two modules, this seems to be working for me so far -- signups and user accounts are being generated as expected when a user completes the transaction.

The core challenges I found, for developers looking to a more permanent solution, were:

1. uc_signup depends on $_SESSION to create user accounts and signups, but Paypal doesn't have access to that info and can't send it to the post URL.
2. uc_payflowlink doesn't call hook_order once it's received confirmation that payment was received. Instead, it calls uc_order_update_status and uc_payment_enter. I'm not familiar enough with Ubercart to know if that's how it's supposed to be, but in any case I had to modify it call uc_signup_order.

Making some progress here -- it got easier when I decided that it's not uc_signup's fault that uc_payflowlink messes with uc_cart_checkout_review_form so that hook_order never gets called.

I ended up keeping uc_signup unchanged, and making the following modifications to uc_payflowlink. The change is specific to uc_payflowlink, but I suspect similar modifications could be made to other Paypal modules.

1. Added the following lines to uc_payflowlink_form, just above 'return $form;'

     // Store $_SESSION in a table, since Paypal won't have access to it when it calls the silent post URL 
     $query = "INSERT INTO {uc_signup_payflowlink_log} (order_id, signup_data) VALUES (%d, '%s')";
     db_query($query, $order->order_id, serialize($_SESSION));
   

2. Added the following lines to uc_payflowlink_response, just below if ($_POST['RESULT'] == 0)

         // Load up the stored session from the db. 
         $stored_session = db_fetch_object(
           db_query("SELECT * FROM {uc_signup_payflowlink_log} WHERE order_id = %d ORDER BY ts DESC", 
           $order->order_id));
   
         // Unserialize the data and load it back into $_SESSION
         $_SESSION = unserialize($stored_session->signup_data);
   
         // Call hook_order('submit') since paypal is confirming here that payment is taken care of.
         // This is equivalent to when a user completes payment in a normal gateway
         foreach (module_list() as $module) {
           $function = $module .'_order';
           if (function_exists($function)) {
             // $order must be passed by reference.
             $result = $function('submit', $order, NULL);
             $msg_type = 'status';
             if ($result[0]['pass'] === FALSE) {
               $error = TRUE;
               $msg_type = 'error';
             }
           // Stop invoking the hooks if there was an error.
           if ($error) {break;}
           }
         }
   

In a nutshell, what this does is create a copy of the user's session in the db just before they leave for Paypal, and reloads that session when Paypal sends a valid confirmation of payment back to the silent post URL. From there, hook_order can be called up normally.

In any case, since uc_signup doesn't seem to be part of the problem, I'll post any additional comments to the similar discussion back at uc_payflowlink, and try to test this refine and test this into a real patch.

Indeed, my proposed fix from #33 is not appropriate. However, I have reproduced the problem here and posted a patch to the PayPal gateway at #700270: Remove hook_uc_order('submit') as it is never called for redirected payment methods. I've also updated the UC_Signup conditional actions so they will work out of the box (without configuration) on more setups.

@anschauung Thanks for posting your solutions here. In my view the best approach is to make sure that payment gateways behave consistently and invoke the proper hooks. The patch I've referenced might provide a decent starting point for the gateway you're using.

just to be clear, to get this working should i update to the dev version of signup integration AND install the patch in #700270 to paypal gateway from ubercart?

will the updating signup integration change the settings? after running update?

thanks for your work to solve this problem.

@blb: ezra-g could say for sure, but I don't think the dev version of uc_signup is necessary. The key is getting the Paypal gateway to call hook_order. ezra-g's patch is similar to what I suggested in #46 -- it calls hook_order before the user leaves for Paypal and depends on conditional actions to complete the order based on paypal's response.

at first glance the patch from #49 above looks great -- thanks, Ezra!

Can someone please sum up for me the steps I need to take to solve this issue? I have installed the patch from #39 and my orders are coming back from PayPal and being marked "Completed" (woohoo!) but the user is never added to the actual signup. Do I need to update to the dev version of uc-signup, or do I need to add/edit some conditional actions to make the last step happen?

Thanks for any directions!

subscribe

subscribing

+1

subscribing

subscribing

subscribe

subscribe

If you're still having this issue after installing the patch in #39, make sure in your checkout panes, you have 'Attendee Signup Information' enabled. That with the patch solved the problem for me.

I'm noticing that the problem occurs when using the uc_credit module with any payment gateway (in my case, InternetSecure) but the problem does not occur when paying by check using the uc_payment_pack module.

I have also had it fail with test_gateway, which never goes off-site in order to process anything.

The patch to the paypal gateway has been applied. This should be resolved with a CVS checkout of Ubercart!

Hi there, I think I'm on the right post having read through the above. When processing through the Test gateway all works fine and signups are added to the list however, when used with uc_paymentexpress signups are not being created. Has there been a fix to this issue or is it a localised to paymentexpress module now?. Any help would be most appreciated

Looks like our fix for this from Ubercart will probably get removed, and we'll have to patch Ubercart in some other way:

http://drupal.org/node/898050#comment-3569890

@tc43: Please open a new issue for uc payments express - that wasn't part of this issue :) .

Now that this was reverted from Ubercart at #898050: hook_order('submit', ...) invoked by paypal module before order actually is submitted, we should work on an alternative issue in the Ubercart queue at #700270: Remove hook_uc_order('submit') as it is never called for redirected payment methods.

Re #67 - the issue for uc_paymentexpress (specific to PXAccess method, I believe) is #946580: PXAccess should invoke hook_order case submit (backport from #700270). That issue is pretty much identical to #700270: Remove hook_uc_order('submit') as it is never called for redirected payment methods and the fix should be the same; I've suggested that we focus on the Paypal fix first to get the best review. I expect there will be several other contributed modules which are similarly affected by this issue.

One solution might be to stop relying on the 'submit' $op in hook_order() all together, and instead use 'save'. Also, instead of storing data in $_SESSION, we could potentially serialize it in the order somewhere, so that it will persist even if the order is finalized as another user, such as when an IPN hits the site.

Marked #962730: Different approach needed with some payment methods, which has some good insight, as a dupe of this issue.

Just some more research. I am writing a custom payment handler that is _not_ a gateway. So my module implements hook_payment_method() but not hook_payment_gateway().

I was getting in trouble, like others, because of hook_form_uc_cart_checkout_review_form_alter(), which the sample code shows removing the default submit. I changed my code to handle the default submit plus mine (which issues a http GET request from drupal_goto(), potentially similar to what a PayPal processor would need to do.

This seems to have fixed the issue, as the temporary signup is now saved on checkout, and converted on order completion.

That said, changing over to hook_order('save') might make this an easier abstraction, since it removes the need to have the $form data in order to process the request.

Another challenge here is that when hook_order() is invoked with case 'save' as a result of an IPN, it would happen as a Drupal user other than the anonymous or authenticated user in checkout. So, we may need to find the session of the user in order to get to the uc_signup data, or store this data somewhere else.

Two details come up in my mind:
a) Whether to continue storing user email and profile information collected during the uc_signup checkout process in $_SESSION['uc_signup']

b) Which event to hook into instead of hook_order case 'submit' for creating temporary signups.

In more detail:

a)
In order->products, each product lists a cart_id, which in the case of anonymous users is the session id of the anonymous user's session. Therefore, we can get to uc_signup $_SESSION information by loading that user's session, if it still exists. An alternative to looking for a user's session information would be to always store this information in the $product->data of each signup enabled product.

Potential benefits storing data in $product->data['uc_signup'] rather than $_SESSION['uc_signup']
- UC_Signup data would persist as long as the order, whereas the anonymous session could expire
- uc_signup information persists even if an authenticated user logs out and logs back in and then continues checkout

Potential drawbacks:
- uc_signup email/profile information wouldn't persist across orders, if the anonymous user does something to get a new order id

My strategy for the present issue is to start by changing as little as possible, ie, sticking with $_SESSION for now.

b) Let's consider which hook events are shared between off-site and on-site payment methods before charging an order. It's important to create the temporary signups before charging an order so that the customer doesn't pay for signups only to have those spaces snatched away by another user in a race condition. Short of integrating with signup_status in some way, we currently create temporary placeholder signups.

I'll return to b soon.

Here's an approach for B that is specifically focused on PayPal, though it could be adapted to other gateways.

We move the processing from hook_order() case 'submit' into a new function: uc_signup_order_prepare(). For on-site payment gateways, we process the order exactly as we do now.

For paypal, hook_order() is never invoked with case submit. Instead, we detect that paypal_wps is the order's payment method and we call uc_signup_order() prepare when the uc_cart_checkout_review_form() is displayed, creating the temporary signups.

In my testing this approach works whether or not the user hits the order confirmation page or the IPN is sent through paypal. I think I may have conflated things in #74 as we don't need to access the session data to find the submitted profile information when finalizing the orders, only when submitting them, and it's safe to assume the user is logged in at this point.

It would be ideal to locate the user's session and clear out the uc_signup data in case the user wants to make another purchase with different email addresses. We could also consider jamming this information in a table somewhere, though that seems wasteful.

Note that this patch depends on #1040970: Not Compatible with Ubercart 6.x-2.x-dev - Update Cart & Checkout buttons on /cart refresh page but do not work as expected, which needs some revision.

Marking as needs review, though I'd like to change the switch in hook_order() to a conditional.

subscribing

Is this patch rock and roll? Can it be committed?

Have a live site right now which and would love to have it working.

Hope this is the right issue queue, but customer signups aren't staying attached to invoices or orders when paypal is used. But the cheque payment method works perfect.

Currently stuck with manually adding user signups to event nodes, and cannot allow multiple signup purchases or for users to purchase for others.. due to signups being lost.

> Is this patch rock and roll?
This patch needs review so that we know if it's ready to rock and roll :).

Manually applied the patch (unix challenged) and it looks like the last order has the signup information attached properly, so it's worked so far! Now the order id and signup id are visible in the signup admin view. Will report back if there's issues with multiples.

This patch looks great, I've tried a version which uses the securetrading payment gateway on my dev server instead of paypal_wps and it works perfectly. Thanks!

Perhaps it would make sense to roll the payment gateway used into a configurable variable?

Well thought it was all working, but when I test with multiple tickets, the signups are still getting dropped here's the error:
Invalid argument supplied for foreach() in uc_signup/uc_signup.module on line 1051

and section of code in reference:

      foreach ($to_signup as $nid => $uids) {
        //Perform the final verification that the node is available for signups in the desired quantity.
        //Note that we do not pass the quantity in order to avoid our own placeholder signups from counting against the number of available spots.
        $node = node_load($nid);
        _uc_signup_node_available($node, 0, $message);
        if ($message) {
          uc_signup_cancel_temporary_signups($arg1);
          return array(array('pass' => FALSE, 'message' => t($message)));
        }
        foreach ($uids as $key => $uid) {
          uc_signup_create_placeholder_signup($nid, $uid, $arg1->order_id);

        }

Further testing shows that some single-qty event node purchases do properly attach the user signup to the order after payment. However it appears on and off, still testing, can't determine the source of the problem yet.

Having similar issue with signups not registering when using Paypal. Check, COD, other payments work fine. Has there been any resolution to this issue?

For our site the issue seems intermittent for now..
The patch has worked for the last two event signup purchases, however did not work for other purchases.
For now stuck with manually creating signups for the user accounts created in checkout process.

Perhaps something the users are doing is affecting the purchase, like cancelling and restarting maybe?

Am thinking about trying the other "on-site" paypal payment method but am unsure how to proceed.

Not working with uc_authorizenet_simdpm. No signups created

modules used:
* ubercart-6.x-2.x-dev (July 8)
* uc_signup-6.x-1.0-rc2, with the patch from comment #75 above (I'll admit that I'm a noob with patches, so I applied it manually).

I have tested a single signup & checkout with both anonymous and authenticated users. I have also tested an authenticated user signing up two others who are new to the site. All scenarios worked as expected; placeholder signups were created, then removed and associated with the proper users. Order status was set to Completed after the transactions. All tests were with PayPal Website Payments Standard, using the PayPal Developer Sandbox.

Hmmm, it looks like I have a similar error as comment #81 in my logs. Actually, it's more similar to #549716: Errors when signup includes $signup->form_data but all of my test signups and notifications have been successful so far. I did not see this error on-screen during the checkout process. But I do see an entry in the logs on every signup - single or multiple, anon or auth.

From the dblog:

 Type: php
 User: Anonymous
 Location: http://mysite.com/uc_paypal/ipn/<order_number>
 Referrer: 
 Message: Invalid argument supplied for foreach() in /var/www/staging/sites/all/modules/signup/theme/email.inc on line 41.

subscribing..

One thing folks could do to help get this feature committed is make sure there is a patch in this issue that applies to the latest dev of uc_signup.

Here's a re-roll which I've tested against the latest uc_signup dev with PayPal WPS. A new an existing user were signed up to 2 events in one order. I tested both by hitting the /cart/checkout/complete page after paying, and without hitting that page.

Attempting to apply this patch to the latest uc_signup-6.x-1.x-dev (from July 22)

 $ patch -p1 < uc_signup-540298-off-site.patch 
 patching file uc_signup.module
 Hunk #1 succeeded at 602 (offset -6 lines).
 Hunk #2 succeeded at 685 (offset 1 line).
 Hunk #3 FAILED at 981.
 1 out of 3 hunks FAILED -- saving rejects to file uc_signup.module.rej

Looks like I uploaded the wrong patch file here. Sorry about that!

I verified that the attached patch applies to the latest dev tarball. Thanks!

Patch applied and tested to 28 July download of dev. Works for PayPal Standard. To note, this will cause accounts to be created by site 'admin' instead of UC so messages will need to be adjusted accordingly.

I can confirm that the patch in #91 above applies cleanly against the -dev release from July 23. Successfully tested with the recent 2.6 release of Ubercart.

Great - This is fixed...again!

Thanks for the reviews!

http://drupalcode.org/project/uc_signup.git/commit/d0e46f4