Ok all of this discussion about roles, recurring fees, and subscription functionality has brought to light another problem which I consider to be fairly serious.

Right now, no matter which approach is used, there is no good method for a user to upgrade to a longer subscription term. For example, someone is on a one month subscription, is a few days before expiration, and wishes to renew but this time with the three month product. Let's look at how this works in each scenario:

• uc_subscriptions: With this approach, a user has a "Renew" link on the "Product subscriptions" tab. If they click renew, it just adds the same term they already had. So if they had one month, they are adding another one month term. This really shoots us in the foot in regards to revenue generation, when we've got customers willing to spend more money more quickly, but have no method for capturing this.
• The only options available to users with the uc_subscriptions approach is as follows:
  1. Wait until the subscription expires, then purchase a longer-term subscription.
  2. Go through the renew process, but rather than "Checkout", click the "Shopping Cart" link at the top of the page. This allows a user to add multiples of any given product in their shopping cart. For example a user could modify the order to be three 1-month subscriptions. However without a discount module installed, there is no easy way to credit users for buying longer term subscriptions.
• A couple of nice features of uc_subscriptions are users can toggle autorenew on and off as they wish, and the subscription expiration date is not set in stone. If a subscription is renewed, the expiration date is automatically extended and updated. With uc_recurring / uc_roles, an invoice is immediately created for the next month, causing a lock in of the "expiration date". Also there is no notion of an autorenew on/off switch. Either a recurring fee is listed in the future, or it is canceled and no longer exists.
• uc_recurring / uc_roles: The options available to users with the uc_recurring / uc_roles approach is as follows:
  1. Out of the box, the uc_recurring / uc_roles method is rigid when it comes to extensions. Either a user can renew on the current product, or he/she can cancel the product and start over again by purchasing a longer term.
  2. One workaround might be to build a set of "subscription extension" products for users. These products would have a role assignment for a given length of time, but no recurring fee. It would be a one-time charge which adds to the current subscription timeline. The issue is the code should be smart enough to say, "if a user already has a subscription, and adds an extension, then automatically update the upcoming recurring fee due date".

I want to make sure it is very clear the problem this causes, so let me provide an example. Say a user purchases a recurring fee subscription which adds a $20 fee on the 27th of each month. On December 24, 2008, the user decides he wants to upgrade to a three month subscription. We can offer a "subscription extension" product for him to purchase, which immediately adds three months to his expiration date. His role expiration is now set to March 27, 2009. However, there is *no* update to the recurring fee. On the account page, it still says the next recurring fee due on December 27. If a user gets charged on 12/27 for another one month renewal, the immediate reaction will be, I just bought three months!

We need to have some reconciliation on all of this. I think two of the most common needs for any subscription site will be the ability of users to control their auto-renew status, and to upgrade/downgrade their accounts ... and in turn have the system understand what implications this has for role expiration dates.