6👍
I don’t know about a “well-tested solution” as you put it, but I would strongly caution against just storing a dollar value in the database and increasing or decreasing that dollar value. Instead, I would advise storing transactions that can be audited if anything goes wrong. Calculate the amount available from the credit and debit transactions in the user account rather than storing it directly.
For extra safety, you would want to ensure that your application cannot delete any transaction records. If you cannot deny write permissions on the relevant tables for some reason, try replicating the transactions to a second database (that the application does not touch) as they are created.
1👍
My language agnostic recommendation would be to make sure that the database that communicates with the web app is read only; at least for the table(s) that deal with these account balances. So, you process payments, and manage the reduction of account balances in a database that is not accessible to anyone other than you (i.e. not connected to the internet, or this web app). You can periodically take snapshots of that database and update the one that interacts with the webapp, so your users have a read copy of their balance. This way, even if a user is able to modify the data to increase their balance by a million bucks, you know that you have their true balance in a separate location. Basically, you’d never have to trust the data on the webapp side – it would be purely informational for your users.
- [Django]-Django-based skill implementation
- [Django]-How To Create A Temp File Structure For Testing
- [Django]-Config Django 1.5.1 for aptana studio 3
- [Django]-Firing notifications at specific times in Django
- [Django]-Django-reversion revert ManyToMany fields outside admin