Payments and fintech

The non-negotiable is a real ledger. Storing balances as a number you increment is how money disappears: two concurrent updates, a retried request, a partial failure between two systems, and now the total does not match the transactions and nobody can say when it stopped. Double-entry with immutable entries means the balance is derived rather than stored, every movement has a counterpart, and reconciliation is arithmetic rather than investigation. It is more work up front and it is the only version that survives an audit.

Payment integration is mostly about the unhappy paths. A network timeout does not tell you whether the charge happened, so every request needs an idempotency key and every response needs to be reconciled against the provider rather than assumed. Webhooks arrive out of order, arrive twice, or arrive before the request that caused them has finished committing. Treating those as exceptional produces a system that is subtly wrong under load; treating them as normal produces one that is boring, which is what you want here.

The regulatory shape of the work depends entirely on jurisdiction and on whether money ever rests in an account you control. Handing off to a licensed provider and never touching funds keeps you outside most licensing regimes; holding balances, even briefly, usually does not. That is a question to answer with a lawyer in your market before the architecture is drawn, because it determines the architecture rather than following it — and it is not a question a development studio should be answering for you.