Open source billing system, feedback on a couple of items

I’m just about finished with my business natural language system for
defining recurring billing periods, but have one major question that I
haven’t decided on. Since I’ll be releasing this as open source very
soon, I’d like to get some feedback.

Right now the language is very open ended. To the point where you can
define billing periods that wouldn’t ever get used in real life.
However since I can’t predict what people might end up actually using
I’m hesitant to limit it.

The basic concept is you can define multiple stages in a complete
recurring billing definition, with each stage being a billing cycle.
The first stage has it’s own unique syntax as it also defines what and
when the first charge is.

In this example we have a biling cycle that is fairly common:

  • charge $10 now then charge $10 every month until cancelled.

Another variation on the same theme:

  • charge $10 now then charge $5 every 2 weeks until cancelled

But there is also the ability to bill on a set day of the month, which
often involves prorating the first charge:

  • charge $10 now prorated then charge $10 every month on the 1st until

Now here comes the part that can get a bit complicated and where
certain assumptions have to be made.

  • charge $10 now then charge $5 every 2 weeks for 3 times then charge
    $10 every month on the 15th until cancelled.

The ‘then’ keyword separates stages. The potentially confusing part
comes when we transition from one stage to another. It’s not
difficult to do the calculations or build in some assumptions about
whether to prorate or not when moving from stage to stage, but there
is probably a high potential for users to get confused. Right now the
only time proration is done is on the first stage/charge.

I also built in the next two types of billing cycles which could also
be confusing for people if they have multiple stages and transition
to/from them:

  • charge bimonthly on the num_suff and num_suff
  • charge every week on day_of_week (sunday, monday, etc…)

In any case, my opinion right now is to expose common stage
combinations via a web interface, and let advanced users define
whatever they want using the bnl directly.