Alrighty, I've got in working order a recurring payments module, and I'm looking for folks to check it out, test it, and see if it makes sense. 
First, I'll try to spell out what the module is not: this is not a one-stop killer module to handle anyone's recurring payment needs. Neither is it an interface to every payment gateway imaginable. It will also never become either of these things. So... what is it good for?
Well, the module is good for providing a framework for your modules to hook into. That's what we want in core, right? 
It does provide a product fee called "recurring fee" that you can attach to a product/SKU. With this you can specify a fee amount, an initial charge (relative to checkout), an interval for further charges, and the total number of intervals. When a customer goes to checkout, the module will restrict them to the payment method options on your site that work for recurring payments. (These can be adjusted in the product features settings form for recurring payments.) Once they complete checkout, the module passes the fee information onto the recurring payment handler of your choice for processing. The rest is up to your handler.
The module also provides a very basic default handler. This depends on you using some sort of credit card payment processor and stores CC data locally to be charged on the proper intervals. There's a cron task to do this automatically, and there's also an admin menu at /admin/store/orders/recurring that lets you tweak the fees and charge them manually. This also includes a few workflow events and a hook_recurring_api($op, $fee) for modules to hook into. I highly recommend using CC encryption if you intend to go this route.
The default handler can be an example in some ways for others to build on in their own modules. It's my understanding that a lot of payment gateways have built in subscription management. In that case, you'll need to code your own functions to setup subscriptions and decide what to do when someone's charge fails or their subscription expires. To be the most flexible, I highly recommend invoking the hook and workflow events you'll see invoked in the uc_recurring_charge() function at the bottom of the module.
Handlers are made by simply implementing hook_recurring_fee($order, $fee) in your module. The arguments are pretty self-explanatory. You can dump $fee with print_r() to see what it contains... basically all the info from the product feature.
I don't intend to work on this indefinitely, and I want it to stay slim. But I want some assessment as to the ease of use for the product feature and the default handler, and I also want to know if anything is lacking for folks to use this as a framework to build their own handlers.
This is the last major hurdle on my beta-do list, so thanks for any help! 
| Preview | Attachment | Size |
|---|---|---|
| uc_recurring.tar | 40.5 KB |
