Anonymous checkout for Recurring Product not listed properly under Subscription Manager and My Account

I have researched this issue a lot. The problem is that uc_recurring_checkout_complete() saves the fee, but it gets called by [I think a conditional action in] uc_payment before the checkout page loads, so the recurring product is tied to user 0. The function will actually get called a second time on the checkout page - but since the recurring fee is already saved, it only saves the User ID the first time.

Some things to try: Make sure you have at least Ubercart 2.7. Also, the last time I had this issue I was using recurring product and fixed it by setting the weight for uc_recurring_product to -1 in my system table.

Wow, thanks so much for this tip! I wasn't even aware my site was having this problem... so many things to watch out for! The SQL above fixes it.

Authorize.net (ARB) still records a Customer ID of zero, but renewals appear to happen correctly anyway based on the Order ID.

The next step after the fix above is to visit the table uc_recurring_users and manually change every row with uid=0 to the correct uid.

I can confirm that this fix works as well. So this issue has to do with the order that uc_recurring_checkout_complete() gets called in versus when $fees are established? This is pretty unsettling. Can the module ship with -1 as the weight?

Re #4: I just uploaded a new patch for this issue: http://drupal.org/node/901940. After fixing these two issues, the module works fine for me (tested on two production websites using Authorize.net CIM)

Here's a patch for the latest development version to do this. Fixed the issue for me! Finally victorious in my fight with this module. I think I'm going to blog about this soon.

The solution in #7 and #3 I think is responsible for the issue here: http://drupal.org/node/1466512 where a recurring fee is created even if the transaction fails during checkout (for both anonymous, and logged in checkout) since uc_recurring_product is called so early with weight=-1. Instead, I have restored the uc_recurring_product.module weight back to its default '0', and come up with the following change to the uc_recurring_product.module file:

/**
 * Implementation of hook_order().
 */
function uc_recurring_product_order($op, $arg1, $arg2) {
  switch ($op) {
    // TODO: Allow admin to create a recurring order from "create order" page.
    case 'submit':
      if (variable_get('uc_recurring_checkout_process', TRUE)) {
        //reload order to capture uid in case checkout was anonymous
        $arg1 = uc_order_load($arg1->order_id);
        if (uc_recurring_product_process_order($arg1) === FALSE) {
          return array(array('pass' => FALSE, 'message' => t('Your order cannot be completed, because we could not process your recurring payment. Please review your payment details and contact us to complete your order if the problem persists.')));
        }
      }
      break;
  }
}

which adds the lines

        //reload order to capture uid in case checkout was anonymous
        $arg1 = uc_order_load($arg1->order_id);

I'm not sure why $arg1 has a uid=0 when this function is called, but by the time $op='submit' the uid has been properly updated in the uc_orders table, so reloading the order captures the correct uid and fixes this issue.

Patch is attached. Nothin' like one line of code for a solid afternoon of work...

Testing the fix in #8, anonymous checkout works on my dev site without needing to have the module at -1. Thanks!

Does anyone know if this patch (or any patch for this problem) has been committed? thanks!

Commited #8 thanks.

The code from #8 does not appear in the latest dev branch for 6.x. However, I can confirm that it corrects the problem with anonymous recurring orders being created as user 0.

Is there some more bleeding edge version available that this has been rolled into?

I could be wrong, but I don't think this was ever committed. I'm looking through the latest commits on the repository viewer. I'm changing the status back to "reviewed & tested by the community".

I have experienced this issue with a fresh download so I agree with #14. Looks like it was never committed (at least not to an actual release... I have not checked the dev version).

I can confirm that #8 works for me. I would like to see this added to dev.

I have tracked this down to a bug in ubercart #1669968: hook_uc_checkout_complete() is called outside of checkout process (when payment is entered). This bug causes the order to be completed before hook_order() submit op is processed. For Anon checkout the fee is supposed to be created with uid 0. uc_recurring_uc_checkout_complete() updates the fee with the customer id when the order is completed. This is messed up by the bug because it runs too early and the fee has not yet been created.

The patch in #8 will temporarily fix the issue but when uc_cart_complete_sale() is removed from uc_payment_enter() it will stop working.

The bug is in ubercart/payment/uc_payment/uc_payment.module function uc_payment_enter()

  // Ensure user has an account before payment is made.
   uc_cart_complete_sale($order);

The simplest temp fix is to set the weight of uc_credit module to 1 which will make uc_recurring process before uc_credit.
UPDATE system SET weight = 1 WHERE name = 'uc_credit'
NOTE: Do NOT set uc_recurring module weight to -1 as this will break checkout.

Update

This issue also affects 7.x-2.x-dev. Unfortunately setting the module weight of uc_credit to '1' as suggested by tinker in #17 breaks checkout when using credit card because the card number is truncated to the last 4 digits earlier, resulting in the full card number being unavailable at the review page where the order is placed. I've confirmed that this problem occurs with the authorize.net arb gateway in 7.x-2.x-dev. I'm not sure if it also affects other gateways but it is likely given the nature of the bug.