There are multiple things going on here ... we've been doing significant testing trying to find some method of a "subscription" model with auto-renew capabilities. Our testing has involved CIM (v0.83, then v0.90) with uc_subscribe (2008-04-11 version), standard Authnet gateway (1.3-1.6) with uc_subscribe (2008-04-11), and uc_recurring (1.4-1.6) with the standard Authnet gateway (1.4-1.6). Here is what we have found:

• In "Test Developer" mode, CIM (v0.90) works perfectly with uc_subscribe (2008-04-11), using UC 1.6. When switched over to production, we get the error messages above and it fails every time. We have previously run CIM v0.83 with uc_subscribe (2008-04-11) and UC 1.3, and we did get it to work successfully in a production environment.
• uc_subscribe can process transactions with the standard Authnet gateway (1.3-1.6), but cannot perform auto-renews. If a user selects the "auto-renew" checkbox under their subscription options, cron will run but the transaction is not processed. Makes sense, since there would be no recurring transaction information stored locally with this method.
• uc_recurring (1.6) with the standard Authnet gateway (1.6) seems as though it's becoming a more viable option since the "cancel" link now works! The Recurring fees "cancel" link on the user profile page did not work until 1.6, we had a hard time justifying releasing it to customers. The one thing about uc_recurring is even with uc_roles installed, it's not as flexible with start/end date manipulation as is uc_subscribe. Obviously I can get to the right date by applying the +/- role expiration option, but would be much better if we could pick specific dates.

So different approaches exist to creating "recurring fees" ... either someone can use uc_subscribe/CIM (when it's working), or they can use uc_recurring/uc_roles/Authnet standard gateway (local storage of encrypted credit card data), and I'm guessing down the road uc_recurring/uc_roles/CIM would be an option.

I really need some understanding on the vision of where this is all headed. Is uc_subscribe functionality going to be pulled into uc_recurring/uc_roles? Will CIM just become another option within Authnet payment core?

My opinion right now is the transaction processing of Authnet standard is *far* more solid than CIM, while the functionality options of uc_subscribe are *slightly* more flexible than uc_recurring/uc_roles.

I want to know which horse I should hitch my wagon to so we're not having to completely rebuild this at some point in the future. Thanks.