BluuPay
Financial Operating System for SMEs
A fintech platform designed to unify payments, wallets, transfers, reconciliation, inventory, point-of-sale operations, merchant analytics, and financial workflows for businesses.
01 / CONTEXT
The problem
High-concurrency financial transactions create risks including race conditions, duplicate webhook processing, double spending, and ledger mismatches. The platform needed to remain consistent even when external payment systems retried or delivered events multiple times.
02 / APPROACH
How I built it
Incoming payment events are authenticated and queued before processing. Transaction operations use unique idempotency keys and transactional ledger writes. Balance-changing operations are protected using row-level locking and distributed locking where required.
03 / CONSTRAINTS
What had to hold
High-concurrency financial operations Duplicate external webhooks Ledger consistency Payment gateway reliability Security-sensitive transactions External system failures and retries
04 / OBJECTIVES
Definition of done
• Build reliable multi-channel payments • Maintain consistent wallet balances • Automate transaction reconciliation • Provide merchant operations tooling • Integrate inventory and POS • Provide secure transaction authorization
05 / THE SYSTEM
Architecture
Verified webhook gateway External payment events are verified using HMAC signatures before entering the processing pipeline. Event-driven processing Incoming payment events are queued for resilient asynchronous processing. Double-entry ledger Financial movements are recorded through an immutable double-entry accounting model. Concurrency protection Pessimistic database locking and Redis distributed locks protect balance mutations. Idempotent transactions Unique idempotency keys prevent duplicate financial operations.
06 / DECISIONS
Key decisions
Use double-entry bookkeeping Why: Financial balances must be derived from auditable ledger movements. Treat payment webhooks as untrusted and duplicable Why: External systems may retry or duplicate events. Use pessimistic locking Why: Concurrent balance mutations require strong serialization guarantees. Use idempotency keys Why: Repeated requests must not result in repeated financial effects.
07 / SHIPPED
Deliverables
• Multi-channel checkout (delivered) — Core capability of the product (see features). • Payment processing (delivered) — Core capability of the product (see features). • Virtual wallets (delivered) — Core capability of the product (see features). • Ledger balances (delivered) — Core capability of the product (see features). • Inter-wallet transfers (delivered) — Core capability of the product (see features).
08 / LESSONS
What I'd keep
• Every balance mutation should be backed by an immutable ledger entry. • External payment webhooks must be treated as untrusted and potentially duplicated. • Financial systems should be designed around failure and retry rather than assuming ideal execution.
What changed
Zero
Ledger discrepancies
to date
Sub-second response time
Transaction validation
to date
Related
// START A PROJECT
Building something with similar constraints?
If it's in your critical path and you'd rather not learn its failure modes live, let's talk about it.