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:
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.
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?
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:
Does this look like it could work?