Credit system: history based or balance based?

Absolutely use both.

• The balance-based way gives you fast access to the current amount.

• The history-based way gives you auditing. The history table should store the transaction (as you describe), a timestamp, the balance before the transaction happened, and ideally a way to track the funds' source/destination.

See the Ruby Toolbox for bookkeeping and Plutus double-entry bookkeeping gem.

In addition, if your credit system may affect users, then I recommend also using logging, and ideally read about secure log verification and provable timestamp chaining.

• For logging details see: techniques for ensuring verifiability of event log files.

• For open source code that does credit, you may want to look into: http://www.gnucash.org/

Adding and deducting credits implies that you might also need to be aware of where these credits came from and where they went. Any time you get into a situation like this, whether it is with currency or some other numerical quantity that needs to be tracked and accounted for, you should consider using a double entry accounting pattern.

This pattern has worked for centuries and gives you all of the functionality you need to be able to see what your balances are and how they got to be that way:

• Audit log of all transactions (including sources and sinks of "funds")
• Running balance of all accounts over time (if you choose to record it)
• Easy validation of the correctness of records
• Ability to "write-once" - no updates means no tampering

If you aren't familiar with the details, start here: Double Entry Bookkeeping or ask anyone who has taken an introductory course in bookkeeping.

You asked for a Ruby on Rails open source solution that you could plug and play into your application. You can use Plutus. Here is an excerpt from the description of this project on Github:

The plutus plugin provides a complete double entry accounting system for use in any Ruby on Rails application. The plugin follows general Double Entry Bookkeeping practices. ... Plutus consists of tables that maintain your accounts, entries and debits and credits. Each entry can have many debits and credits. The entry table, which records your business transactions is, essentially, your accounting Journal.

yes, use both.

• On top of that, you'll sometime need to reverse a transaction/transactions.When doing that, create a new reversed transaction tonotate the money transfer.

• sometimes, You'll need to unify several transactions under one roof. I suggest to create a third table called 'tokens' that will be the payments manager and you'll unify those grouped transactions under that token.

  token.transactions = (select * from transactions t where t.token = "123") for example