Ubercart

I recently posted some of my own thoughts on recurring billing (includes a patch with a working solution on my issues):
http://www.ubercart.org/forum/ideas_and_suggestions/10133/uc_recurring_t...

The problem I see with your post is it just focuses on authorize.net - there are other options out there and for ubercart to have a solid recurring billing option it needs to be flexible and support many different gateways.

Some gateways i have personally used or investigated for recurring billing are:
* Paypal provides a good option for subscriptions, everything is reported back via their IPN (I have used this solution for a number of years now)
* Google looks to be providing a reasonable XML api for recurring payments
* securepay.com.au is a gateway I use in Australia and have used their triggered payments api to handle recurring billing for a few years, it has all the advantages of managing credit billing completely yourself without having to store the actual credit cards
* eway.com.au is another australian gateway that has added recurring billing (haven't used them)

What should be provided for recurring billing is a solid api and standard process for any payment gateway to work with it, if a gateway supports recurring billing they should just provide this in their gateway module and uc_recurring picks this up and provides this as an option to end users setting up the site. uc_recurring in turn should prove all the infrastructure to tap into other parts of ubercarts systems like uc_roles.

One of the other annoyances I have with uc_recurring is there is no way to support both paypal subscriptions and another credit card subscription option like you can currently do with normal orders. The patch I have provided here fixes that by allowing ubercart to support more then one recurring billing option, as well as automatically handle uc_role renewals, done through the conditional actions:
http://drupal.org/node/426466

That patch is not complete, really just a test on the idea to show it works, but in this process I have come across a few other minor issue in the way recurring fees are handled, including the order of when the recurring fee is setup, at the moment it happens after the order is completed, the problem with that is that gateways like Paypal that really need to charge the order and setup the recurring fee at the same time and cannot with with this structure.

I am keen to hear from anyone with a view on recurring payments and how they would like to see them handled, is what I have proposed a good solution or are their better options/ideas I haven't thought of?

I fully agree that ARB is terrible. I also want to note that the built-in CIM is terrible as well. The contributed CIM module has much more function.

I also agree that recurring payment should not be locked into Auth.net.

Another major issue that I've seen in the community here is the integration of recurring payments and role promotions. There's a major thread about this somewhere, but no good conclusions came from it. As it stands now, the whole process of "subscriptions" is clumsy and takes a whole bunch of hacking. Considering the fact that we're in web 2.0 and online software services are growing, this functionality deserves more attention.

I believe that uc_recurring and uc_roles do not have a project page on Drupal.org because they fall under the Ubercart umbrella.

I think what we need is some way to separate out the various Ubercart modules for discussion. Maybe break up the dev forums? We also need some kind of wiki or community documentation. The current documentation is sparse and old. The documentation forum is... messy. A wiki would be an easier format to work in. That way the people who really know how things work can share their knowledge in an easily browsable format.

Sorry for the scatter-shot post.

I have a consulting company that sells reoccurring monthly packages most of my payments are not through a gateway usually i get a check in the mail. I thought ubercart would automatically create a new order when the time arrived according to these posts it does not?

My work flow is kind of like this;

Arrive onsite do some work and sell a monthly/yearly subscription

login to ubercart as admin create an order

print a invoice (not sure how the reoccuring stuff works i have added it as a feature to the product)

accept a check right there and then

apply a payment

hope that ubercart will somehow send me and the client a new invoice when one month has passed or at least alert me that i have to manually bill the client again. Do not think this is happening.

Note on invoice creation:
Still tryin to decide if each client should have an account because this makes it hard to create orders for them later always have to enter the address info. If someone has a solution for this please let me know right now i use uc_addresses but it only works for past orders not user addresses.

Will this also cater for Usage Based Invoicing as well as a regular monthly fee?
ie. I have a monthly subscription of X But there is also an addition charge based on usage (for this example lets say SMS this month I use 20 text messages next month I use 100)

so the line items would be:

subscription $x
Usage cost(SMS) $Y

Total $total

My question is can I trigger a payment on the whole invoice automatically or just the original subscription.

Thanks

Using Drupal 7:

I have an original price of $30.00 and then when I look @ the recurring fees, it shows 3.00 and not the 30.00. I have all the settings as the same as the sell price and when I go to the edit form, it shows the recurring fee of $30.00.

Any ideas on how to fix this? Thanks.

Hi -
I run Ubercart with a subscription service that uses recurring payments. We recently decided to remove the recurring payment functionality in favor of just simple subscriptions that expire. What is the smoothest way to keep current subscriptions but remove the recurring payments?

Would simply turning off the module do the trick? Could that technique corrupt current subscription orders?

Thanks!
Kent