You do realize the entire banking system is not built with the idea of ACID/transactional databases in mind? You only really need durability guarantees to implement banking properly. Bank accounts are eventually consistent logs of immutable transaction data which are reconciled in batch.
You might not need ACID during the recording of each charging transaction; however, without ACID, you won't be able to correctly apply each transaction against your account balance during the reconciliation batch processing. Marking each charging record as charged and updating your account balance must be in one transaction, whether relying on the database transaction support or building your own transactional log.
So at the end of the day (yes end of the day processing), ACID is needed.
The account balance is calculated as a function of adding all the debits and credits together. Bank accounts are not stored as some kind of balance value that gets mutated over time. The balance is simply the result of some operation that is cached. It's quite simple. No ACID required. Most of these systems at large banks were built in IMS long before relational databases even existed.
>"You do realize the entire banking system is not built with the idea of ACID/transactional databases in mind?"
Well, I was referring to payments/transactions, not banking. As I specifically said, we are building a third party payments aggregator (TPPA). So, we handle transactions; we're not a bank.
In our case, there are many scenarios where ACID is needed. A couple of the most basic are the need to rollback a transaction (e.g. if it was cancelled, or if it did not succeed) and the need to recover from a failure (specifically, to get back to a consistent state to resume a failed transaction).
