2

Introduction

I'm working on an application where organisations pay for each user they add to their 'environment'. Organisations have a credit/balance, and as long as the user is not removed, the organisation pays a small hourly fee per user. Organisations can choose between recurring and one-time payments. An invoice will be made for every payment.

I'm trying to find the best way to implement this. So far, I've come up with two possible solutions:

Option A

The first possible solution is to 'log' every change of state in the system regarding users, payments and pricing.

When an organisation adds or removes a user, a log entry will be written. When a payment is being made, a log entry will be written. When the price changes, a log entry will be written. Every relevant state will be recorded.

Using these these logs, the application can calculate the credit/balance.

Option B

The second possible solution is to implement a physical credit/balance. Instead of logging everything, an hourly cron job will run that subtracts the fee per user from the organisation's credit/balance.

This second option seems much simpler to me. It avoids making all kinds of complex calculations using multiple tables and records. I'll probably need to log payments and stuff anyway, but I'm not using those logs to determine the credit/balance.

Any thoughts? What's the best way to implement this kind of system?

Edit

After considering @Ewan's answer, I do believe he brings up a good point. That's why I'm going with option A, or something that looks like option A.

Here's a simplified DB schema I created:

DB Schema

Does this look like it could work?

Willem-Aart
  • 325

2 Answers2

7

Option A is far superior.

Imagine your cron job crashes and doesnt run over a weekend. Or you find a bug and its been calculating the price slightly wrong for ages. You would have no way to figure out the correct bills.

In any system like this you have to consider how you would check the results. so you need to be able to not only bill correctly, but go back and explain the bill calculation and prove it is correct.

Ewan
  • 83,178
1

Have you considered something like a combination of the two?

Once per hour, compute the charge, and record everything that comprises that charge in a write-only table. Then once/month (or however long) an invoice can be generated off that data. If there's any disputes or discrepancies, it should be relatively easy to track down.

This doesn't take the place of having good logs, which is what you would get in Option A.

emragins
  • 535