Commerce Recurring Bill

Future home of a new periodic billing framework for Drupal Commerce. The framework includes a billing entity, a subscription entity and a subscription product entity. Payment method implementation is separate and provides the bridge between this framework and commerce entities. As the modules were bespoke software for a particular product (software license subscriptions) , we are looking for coders and co-maintainers of the project to trim out the fat and prepare it for a dev release.

The project enables multiple subscriptions to multiple subscription products. One recurring bill can hold unlimited subscriptions (or just one). UI enables user's changing billing information, upgrading and downgrading subscriptions, canceling a subscription (or all subscriptions). Entity controller recurs bills ONLY if they have been paid, otherwise rules methods and cron will put them in past-due and then later in a failed state, eventually locking the failed state subscriptions from further editing. Roles are granted on a per-subscription-product basis. A notification listener system and/or csv transaction report upload form provide the point of integration with local payment notifications and the recurring process. Full views implementation, rules, tokens, etc. are all at hand as the entities here were crafted to emulate the functionality and style of the 'commerce_order' entity.

Subscriptions can be in multiple states: complimentary (no bill), trial (term set on the subscription product), manually managed (i.e. NOT using a credit card), future (postponed subscriptions that start at a future date) all are possible.

Payment method implementation has been done only for First Data at this point. This was both a blessing and a curse. The benefit is that we have a solution for payment gateways that do not provide in their API an 'account status' type of call, nor any payment notifications (ala Recurly) which is the worst case scenario. This required the project to be extremely tight as not to fall out of synch with the payment gateway data. This came at the expense of a lot of protective measures which ensure the sanity of local data.

Project dependencies: commerce, date, role_reference.