Ask YC: Billing Systems
6 comments
I've written three billing systems. None had any common code, and in retrospect it's doubtful that it would have made much sense. The business structure just had too big of an impact on the design. If all the businesses you're trying to serve have a similar business model (e.g. shipping physical stuff, or digital subscriptions, or selling software downloads) then you might get some leverage, but as soon as you throw in anything weird (refunds, credit card holds, recurring billing, staged billing, payment by something other than a credit card, etc. etc. etc.) it can get very, very complicated. Which is probably why there's not a one-size-fits-all solution out there.
I have written a 3rd party billing application like this, for the domestic service industry, and the major hurdle you will have to get over is that merchant account issuers won't give you an account.
They get one whiff of "3rd party processing" or "payment service provider" and their fraud alarms go off. Certainly in the UK they (Major banks & Paypal) will not issue me with a merchant account, and the reason they cite is that it's too big a fraud risk. I can see how it would be an easy way to launder money.
If you manage to overcome this problem, I'd love to hear about it :-)
They get one whiff of "3rd party processing" or "payment service provider" and their fraud alarms go off. Certainly in the UK they (Major banks & Paypal) will not issue me with a merchant account, and the reason they cite is that it's too big a fraud risk. I can see how it would be an easy way to launder money.
If you manage to overcome this problem, I'd love to hear about it :-)
This is not a particular problem at all in this case. The business in question is not a payment service provider at all, they only happen to process billings and disbursements on behalf of third parties as a part of the service they provide to the end user, and only in certain cases. They have also been doing so for some time. This is a b2b scenario with no current need for credit card payments at all; its all wire xfer, chq, eft etc.
Ever looked at Apache OFBiz? It's backed by fairly detailed/complex models that might be able to do what you need. Even if it isn't, the community around it is full of people who 1) get code, and 2) get business uses of said code, so you might have some people willing to at least bounce ideas off of.
Billing systems are a black box. They're typically geared for one product / company and that's it.
Do us all a favor and open source your code!
Do us all a favor and open source your code!
Amazon Payments & Billing Services might be useful
So I thought it seemed sensible to ask for insight from the larger community.
Its easy to implement some variation on the "double entry universal ledger" idea, and we've found this adequate for a whole range of accounting / billing problems. However, there seems to be a whole class of billing use cases that would be greatly facilitated by a more sophisticated approach:
- when a service provider bills a customer, a whole series of entries/transactions might actually result. For example, it may be a third party who is actually providing the service, in other words the service provider is actually billing on behalf of this third party. Also, at the time of this billing, some of the entries/transactions might relate to ascribing a portion of the billing to various OTHER third parties (eg commissions, service fees to be collected for disbursement to other providers which exist in the service chain, etc.). Then also, in some cases there are service tax ramifications, so there may be a tax portion to the billing which may likewise have to be split among various third parties. This all needs to be recorded at the time of the original billing, since it reflects earnings accrued to the various parties under general accounting principles.
- the primary requirement being that each third party must know at any point what money has been ascribed to it (even if no payment has been received yet) -- but no funds for the billing will actually be released to anyone, until the billed customer has paid over and cleared some funds (might be in the form of a chq or eft).
- at the same time, all information that goes into calculating a billing, must remain associated with that billing. (E.g. all formulas and all their parameters, such as tax rates etc -- these can obviously differ vastly for different billings). The reason being that a partial reversal could be made against a billing at any point in future, and money must then be "pulled back" proportionally from any third party to which it has been ascribed, according to the original rules which were in effect at the time of that billing. (The rules might have changed in the interim, eg different third parties might have become associated with an account, commission rate might have changed etc).
Now it seems to me that this class of requirement surely cannot be that uncommon -- and yet I seem unable to find any reference to this class of problem in any open source billing system I can locate; neither can I seem to find any books or other materials which might cover implementation patterns and best practices for these classes of system.
For the project that needs this, we can of course design and code up something ourselves (e.g. a ledger that tracks only cash accounts with a separate billing structure tracking the rest, settling to and from the cash accounts); and if it turns out there is a broader need for this type of use case, the project might support open sourcing this code.
Thus on the one hand, I would be interested to learn of anyone else who has faced a similar type of use case, and how this was approached, and whether there would be value in creating a new open source project that speaks to this class of requirement.
On the other hand, it always seems prudent to write less code and see where one can piggy-back on existing projects -- so if anyone knows of any existing open source that can do this, please let us know!