Authorize.net recently added a new feature called the "Customer Information Manager" to store/manage customer data for recurring billing. For those who use them, this will save them having to store cc data on their own servers. The guide can be found here: http://www.authorize.net/support/CIM_XML_guide.pdf
They provide sample intergration code here: http://developer.authorize.net/samplecode
Hopefully that can help.

I am not sure if we have it clear what situations we might have for recurring events.

1. The situation that someone buys a product but wants to pay for it in several stages.
What we need then is a partial payment for every period, and a single order and invoice.

2. The situation that we have a product that we want to renew every period, with a new order and invoice

3. The situation that we would like to have a order recurred, with a set of products included.

This module is focusing on the first situation, while subscriptions is focusing on the second situation am i right?

Zahor - You're in luck, I've written a CIM module. Check it out in contrib if you're interested.

Ryan - I've done some testing of the recurring module with the CIM module. It seems to work quite well, just using the default handler (no work for me to do! ) but I think I found a couple bugs and have a couple thoughts for you:

1) $method isn't defined in uc_recurring_charge. I think you can just replace it with 'credit' since that's the only option, right?

$func = $gateways[$keys[0]]['credit']; //EDIT from: $func = $gateways[$keys[0]][$method];

2) $order_id and $amount aren't defined in uc_recurring_charge either. Here's what I think the charge line should look like:

3) Your default handler works well with CIM (since CIM is just like charging a credit card normally, only the number isn't stored in your database) except for one line. In uc_recurring_recurring_fee you check that the payment method is 'credit'. In the CIM module I briefly change the payment method to 'cim' so that I can handle pre-orders / partial payments. What would you think about changing that line to:

4) I noticed that you commented out part of this query:

Was that just for testing, maybe?

5) I noticed that you're logging payments to the usual uc_payments table, which makes the order balance go negative. What do you think about using a new uc_recurring_payments table instead? There could be a pane or tab on the order page that shows those payments separately. Seems a little more intuitive...although a bit more work as well...

Hope that's helpful. I'll let you know if I come up with anything else.

Best,
Chad

Sounds good, Ryan. I can take care of the cim method on my end...the easiest way might be for me to create a new handler, which just changes the payment method to credit briefly, calls your handler, then changes it back to cim. Alternatively, if you ever wanted to integrate support for partial payments and pre-orders into the uc_credit module, I could probably go back to leaving the payment method as credit in the cim module.

There is one other point that I think may be important. I believe that most payment gateway modules will need to mark recurring transactions as recurring when they're processed. (In Auth.net AIM this is the x_recurring_billing option). The card associations seem to require this, plus I've read some reports that setting this option can save you some transaction fees, since the recurring transactions (except for the first) won't have any CVV data and might otherwise get downgraded as a result. If anyone has any experience with this I'd be curious to get their input.

The thing I'm not sure about is how to handle an order that contains some recurring and some non-recurring items. Should the whole order be flagged as recurring to the gateway? Or should the recurring portion be charged separately, with the flag? Or can we wait until the automatic recurring charge is made (as opposed to the first charge made when the user checks out)?

I'm just not quite sure how this is supposed to work. If anyone has any experience with this, it would be very helpful.

Best,
Chad

Aye, the recurring fee handler in core is simply a default one to work with the credit module. The other modules will need their own handlers if they're going to handle the fees, and in that case you'd enable them in the recurring fee product feature settings as valid payment methods.

I guess where the pinch is is that right now we use a single handler to process recurring fees. I guess that means you'd need a custom module to route it to the correct one depending on their payment method selection... which is unintended.

Good feedback, though... will have to work that out as we go. Thoughts? I wasn't intending to write a hook to declare fee handlers, but maybe I'll have to so you can choose a different one for every enabled payment method? Oof.

Oh yeah, as is it works off a hook on a per-module basis. So, any module implementing the hook will be listed in the settings menu as a recurring fee handler. You just can't specify a different handler depending on payment method right now. If you had a custom module and implemented your own hook_recurring_fee(), you could have that check $order->payment_method and kick out to a different charge function accordingly. So... it's possible, just roundabout right now.

I put in the issue queue the postgres support. you should find it here:
http://www.ubercart.org/issue/3786/postgres_support_uc_recurring

Don't know if you ever figured this out but it was driving me crazy too. You have to first enable recurring fees in the Product Features section of Store Configuration. Then create your product. Then go into Edit on the product and click the Features tab. That's where you can assign a recurring fee to your product. Not sure about manually cutting users off yet though.

Ryan, Is there any way to set the number of billing cycles so that it's indefinite? I'm using Chad's Authorize CIM module and was wondering about this.