Hi j0rd,

I don't feel we can just ignore paypal/google or other gateways that have built in features to take care of recurring billing. As you said they are one of the more popular options - which I would guess is considered a lot by those just starting out with a particular business as they are cheap to setup.

The fact is that ubercart is not an enterprise level ecommerce system and in many cases it is installed on shared hosting by people with little technical background (which is a recipe for all sorts of security concerns that I am not sure can all be addresed within the software itself). Ubercart does have the test_gateway that stores card details already - anyone with the technical understanding of security to manage credit card details themselves should be able to implement a solution that stores credit card details and mange everything themselves with little difficulty from that module - and we could put together somewhere in some docs a recipe for those wanting to do this with uc_recurring with some references to PCI compliance issues that need to be considered - ie: make it easy to do for those with the technical skills, but hard for those that don't (a good example of a non-technical person blaming ubercart for a security compromise - imagine the same person haveing a 1000 credit card details stolen and having the merchant providers/banks on their butt).

I think we should be able to solve the problem for both types of gateways with the one module. uc_recurring should implement solutions for a lot of the functionality (that we need) so it can manage everything itself if required (e.g. canceling, refunding etc...) - we can use the test_gateway as the test gateway to implement all these features. But then I would like to see the ability to override the built in functionality with a payment gateway's own implementation or disabling that feature completely if a gateway doesn't support it. The current solution for adding other features in uc_recurring was the "fee_ops()" callback that a gateway could implement. We need something like this that a gateway can expose what feature are handled by uc_recurring(ubercart), what are handled by the gateway and what are disabled.

I guess one issue is that this it would require a lot of internally checking to make sure that enabling/disabling gateways or adding/editing billing schedules is allowed by the user - you don't want to allow a complex billing schedule if the gateway(s) enabled doesn't support that option or allow you to disable one of your gateways that allows all the complex billing options that are setup without warning the user somehow. As for things like cancel subscriptions when deleting an account that should be able to be handled though a hook (if ubercart can't cancel the subscription from ubercart then you can't delete the account and are warned to cancel that first - I think I would want to be warned that a subscription is active before deleting an account anyway)

I am definitely excited by the schema you have described and looking to take on some of those suggestions as that really would expand the possible functionality of uc_recurring a lot, especially the schedules/extension schema's.

The only thing I would add is that for the solution I am suggesting to work well it would be more ideal if the payment gateway architecture was all object oriented code. I have been thinking about a lot of the issues above and I keep thinking that this would be so mush easier if the gateways where all written in OO. I posted the following to see if anyone else is thinking about this also - http://www.ubercart.org/forum/ideas_and_suggestions/10771/object_oriente...