Ledger vs balance column
Storing only a balance field is fragile. Production wallet systems use a transaction ledger — every credit and debit is a row. Balance is computed from the ledger or updated atomically with each entry. This gives you audit trails, dispute resolution, and reconciliation for free.
Core wallet operations
Every VTU platform wallet needs these operations:
- Credit — payment gateway funding, admin adjustment, referral bonus
- Debit — service purchase (airtime, data, cable, electricity)
- Hold — reserve funds during pending provider calls
- Release — confirm debit after successful delivery
- Refund — reverse failed purchases
Atomicity under failure
When a user buys data, the flow is: check balance → debit wallet → call VTU provider → update status. If the provider fails, decide: auto-refund, mark pending for manual review, or retry. Never leave a debited wallet with no transaction record.
Use database transactions so debit and ledger entry happen together. Idempotency keys prevent double-debit if the user taps buy twice or the network retries.
Postranet and UzobestGSM handle high transaction volume — wallet architecture must be designed for scale from the start, not patched later.
Admin and reconciliation
Build admin tools to search transactions, filter by status, manually credit or debit with reason codes, and export reports. Your support team will need these on day one.