Recurring subscription module creates duplicate orders

I am seeing this behavior as well.

I created a $5 recurring subscription that renews every 2 days. This is the result of the initial checkout of the order:

The uc_recurring_users table contains these entries:

Is the first entry the initial $5 charge to kick off the subscription?

According to the logs, both entries had their recurring charges attempted by the A.net CIM method. (attempted but failed, due to an unresolved issue)

I am also seeing this behavior using authorize.net ARB and the 7.x-2.0-alpha3 version of this module. I have cron running every hour, so it seems likely to me that a new order is being created on every cron job. I checked the authorize.net account and the subscription is correct and not being charged incorrectly.

I just saw this thread that might be useful - http://drupal.org/node/1361778

Got the same issue here, anyone got fixes for this?

I believe that I have this issue too. I have the DEV Ubercart (ubercart-7.x-3.x-dev-20130309.tar.gz); UC Recurring version 7.x-2.0-alpha3, drupal core is 7.23.

I did some testing, and found the following information. What seems to be the cause of the problem:

I have created a production with a one year recurring fee; another with a one day recurring fee.

They each have one row in uc_recurring_products:
select * from uc_recurring_product;
+------+---------+------------+----------------+------------------+------------------+
| pfid | model | fee_amount | initial_charge | regular_interval | number_intervals |
+------+---------+------------+----------------+------------------+------------------+
| 4 | hosting | 0.000 | 1 years | 1 years | -1 |
| 5 | | 12.000 | 1 days | 1 days | -1 |
+------+---------+------------+----------------+------------------+------------------+

(Note the fee_amount in the "hosting" product is incorrect - it should be AUD $235 excluding GST)

They each have one row in uc_products:
select model, sell_price, ordering from uc_products;
...
| hosting | 260.00000 | 0 |
| maint | 11.00000 | 0 |
...

ONE order was made for each of them: Order 6 for hosting; and order 9 for maint.

The relevant orders each have TWO ROWS in uc_recurring_users:
select fee_title, from_unixtime(next_charge), regular_interval, from_unixtime(created), order_id, fee_amount, order_product_id from uc_recurring_users order by order_id;
+---------------------------------------------------+----------------------------+------------------+------------------------+----------+------------+------------------+
| fee_title | from_unixtime(next_charge) | regular_interval | from_unixtime(created) | order_id | fee_amount | order_product_id |

...

| Renewal of order 6 | 2013-08-21 01:21:08 | 0 | 2013-08-20 15:21:07 | 6 | 258.500 | NULL |
| Renewal of product Website Management and Hosting | 2014-08-20 15:21:08 | 1 years | 2013-08-20 15:21:07 | 6 | 235.000 | 6 |
| Renewal of order 9 | 2013-08-23 00:28:24 | 0 | 2013-08-22 14:28:24 | 9 | 11.000 | NULL |
| Renewal of product Test Maintenance Product | 2013-08-23 14:28:24 | 1 days | 2013-08-22 14:28:24 | 9 | 12.000 | 9 |

...

When I check uc_orders, I find a number of orders related to ORDER 6, as follows:
select order_id, order_status, order_total, product_count, from_unixtime(created), from_unixtime(modified), host from uc_orders order by order_id;
+----------+--------------+-------------+---------------+------------------------+-------------------------+--------------+
| order_id | order_status | order_total | product_count | from_unixtime(created) | from_unixtime(modified) | host |
+----------+--------------+-------------+---------------+------------------------+-------------------------+--------------+

...

| 6 | completed | 258.50000 | 1 | 2013-08-20 15:20:42 | 2013-08-20 15:21:48 | 192.168.1.10 |
| 7 | pending | 23.50000 | 0 | 2013-08-21 10:50:41 | 2013-08-21 10:50:41 | |
| 8 | pending | 23.50000 | 0 | 2013-08-22 14:23:49 | 2013-08-22 14:23:49 | |
| 9 | completed | 11.00000 | 1 | 2013-08-22 14:27:59 | 2013-08-22 14:45:15 | 192.168.1.10 |
...
| 15 | pending | 23.50000 | 0 | 2013-08-22 14:45:43 | 2013-08-22 14:45:43 | |
| 16 | pending | 23.50000 | 0 | 2013-08-22 14:49:47 | 2013-08-22 14:49:47 | |
| 17 | pending | 23.50000 | 0 | 2013-08-22 14:54:59 | 2013-08-22 14:54:59 | |
| 18 | pending | 23.50000 | 0 | 2013-08-22 15:17:30 | 2013-08-22 15:17:30 | |
...
| 20 | pending | 23.50000 | 0 | 2013-08-22 16:13:41 | 2013-08-22 16:13:41 | |
| 21 | pending | 23.50000 | 0 | 2013-08-22 16:26:26 | 2013-08-22 16:26:26 | |
| 22 | pending | 23.50000 | 0 | 2013-08-22 16:38:07 | 2013-08-22 16:38:07 | |

I am doing all of this in a development environment, so CRON is set to run every few minutes so we can get test results back quickly.

FROM THE ABOVE: I THINK that an error was made on creation of the product (either user error or an error in saving data). The system is creating a new order with no customer, no products every time CRON runs. The order is initially created with a fee amount of 0, then updated to 23.50 - which when I look in the uc_order_line_items table relates to the GST on $235.

What I was trying to test at the time was if I changed the price on a recurring product, would the recurring fees update? SO the product hosting was initially created with a price of $235 excluding GST, with the recurring fee the same as the initial price. I placed my initial order, and checked that the order value and recurring fee was correct.

I then updated the price on the product to $260, with the recurring fee $258. The recurring fee did not update on the original order.

I hope the above is related to this issue (and not muddying the waters) and that it helps you find the cause.

Because I am working in a development environment, I am very happy to do any testing you need to help resolve this problem - just let me know what you want me to do!

Also, I am new to the Drupal community - please let me know if I should have provided the above information in a different way.

are you using paypal gateway or ??

I was testing using bank transfer and COD - also PayPal, but the problem was coming up with all three payment methods.

I suspect the module failed to check whether a valid subscription order exists or not and just dumbly creates new order.

The problem is in the uc_recurring_renew($fee) function, it is broken.

adding the $fee->attempts = 1 cuts down the unwanted clone to 2 from 5 order create.

    if (isset($fee->data['retry_order_id'])) {
      unset($fee->data['retry_order_id']);
    }
    
    // Mark attempt successfull
    // @mark experimental
    $fee->attempts = 1;
     

but I think the function need to be revamped completely.

version update

Another bug found :

based on 2.0-alpha4 on file uc_recurring_hosted.paypal.ipn.inc line 239 :

From :

/**
 * Validate Paypal IPN.
 */
function _uc_recurring_hosted_paypal_ipn_validate($ipn) {
  if (_uc_recurring_hosted_paypal_ipn_is_duplicate($ipn)) {
    return FALSE;
  }

  // @todo: any reason we can't use http_build_query() here?
  $req = '';
  foreach ($_POST as $key => $value) {
    $value = urlencode(stripslashes($value));
    $req .= $key . '=' . $value . '&';
  }

  $req .= 'cmd=_notify-validate';

  if (variable_get('uc_paypal_wpp_server', '') == 'https://api-3t.paypal.com/nvp') {
    $host = 'https://www.paypal.com/cgi-bin/webscr';
  }
  else {
    $host = variable_get('uc_paypal_wps_server', 'https://www.sandbox.paypal.com/cgi-bin/webscr');
  }
  $response = drupal_http_request($host, array(
        'headers' => array(),
        'method' => 'POST',
        'data' => $req,
      ));

  // @todo: Change this to property_exists when we have a PHP requirement >= 5.1.
  if (array_key_exists('error', $response)) {
    watchdog('uc_recurring_hosted', 'IPN failed with HTTP error @error, code @code.', array('@error' => $response->error, '@code' => $response->code), WATCHDOG_ERROR);
    return FALSE;
  }

  if (strcmp($response->data, 'VERIFIED') == 0) {
    watchdog('uc_recurring_hosted', 'PayPal Recurring IPN Transaction Verified.');
    return TRUE;
  }
  elseif (strcmp($response->data, 'INVALID') == 0) {
    watchdog('uc_recurring_hosted', 'IPN transaction failed verification.', array(), WATCHDOG_ERROR);
    uc_order_comment_save($ipn->order_id, 0, t('An IPN transaction failed verification for this order.'), 'admin');
  }
  return FALSE;
}

To :

/**
 * Validate Paypal IPN.
 */
function _uc_recurring_hosted_paypal_ipn_validate($ipn) {

  // @todo: any reason we can't use http_build_query() here?
  $req = '';
  foreach ($_POST as $key => $value) {
    $value = urlencode(stripslashes($value));
    $req .= $key . '=' . $value . '&';
  }

  $req .= 'cmd=_notify-validate';

  if (variable_get('uc_paypal_wpp_server', '') == 'https://api-3t.paypal.com/nvp') {
    $host = 'https://www.paypal.com/cgi-bin/webscr';
  }
  else {
    $host = variable_get('uc_paypal_wps_server', 'https://www.sandbox.paypal.com/cgi-bin/webscr');
  }
  $response = drupal_http_request($host, array(
        'headers' => array(),
        'method' => 'POST',
        'data' => $req,
      ));

  // @todo: Change this to property_exists when we have a PHP requirement >= 5.1.
  if (array_key_exists('error', $response)) {
    watchdog('uc_recurring_hosted', 'IPN failed with HTTP error @error, code @code.', array('@error' => $response->error, '@code' => $response->code), WATCHDOG_ERROR);
    return FALSE;
  }

  if (strcmp($response->data, 'VERIFIED') == 0) {
    watchdog('uc_recurring_hosted', 'PayPal Recurring IPN Transaction Verified.');
    return TRUE;
  }
  elseif (strcmp($response->data, 'INVALID') == 0) {
    watchdog('uc_recurring_hosted', 'IPN transaction failed verification.', array(), WATCHDOG_ERROR);
    uc_order_comment_save($ipn->order_id, 0, t('An IPN transaction failed verification for this order.'), 'admin');
  }
  return FALSE;
}

Somehow paypal needs UC to send validation code that will mark the IPN as received. Thus stopping it to resend more IPN that will create multiple orders.

Needs testing and report if this is working...

Same issue . above code does not work .Did any one able to solve this then respond

+1

I'm also seeing a new order created on every cron job. Is there a fix for this? I see a newer development version. (I'm using the 7.x-2.0-alpha3+10-dev).

Looks like the newest development version also has this problem. Has anyone gotten this bug fixed? I get a new blank order on every cron run. I've been cleaning up the extra orders with the mysql command DELETE FROM `uc_orders` WHERE order_total=0;

UCRPS creates a new order for each concerned account every time cron runs.
Without a fix, this module is just unusable.

Hello @brulain. This module for me create order, when current time > field next_charge from table uc_recurring_users. Maybe you didn't set settings for product.