◐ buildingFinTech · Backend · Infrastructure

EscrowPay

Standalone escrow engine — working backend, frontend in progress.

Node.jsPostgreSQLSupabaseREST APIDouble-entry Ledger

// the problem

Escrow without a proper financial engine is just a promise.

The current Zolarux escrow flow works — but it is application-level logic sitting on top of a general-purpose database. As transaction volume grows, this approach will hit limits: no audit trail, no double-entry integrity, no idempotency guarantees, no atomic multi-step operations. EscrowPay is a standalone escrow engine built to replace this with a proper financial infrastructure layer — one that could eventually power escrow for any Nigerian social commerce platform, not just Zolarux. The backend is complete; a frontend and public release are still ahead.

// my role

What I built and owned.

Sole architect and engineer. Backend is built and functional — Node.js/Express API, PostgreSQL schema, and core escrow logic. Frontend work has not begun.

✓System architecture — ledger design, engine separation, API contract

✓PostgreSQL schema — 5 core tables with double-entry integrity

✓Node.js/Express backend — REST API, request validation, error handling

✓Escrow engine implementation — fund holding, release triggers, dispute states

✓Wallet service — balance tracking, atomic credit/debit operations

✓Idempotency strategy — preventing double-processing under network failures

// architecture

How it's built.

Four distinct engines handle separate concerns: the Ledger Engine maintains the double-entry record, the Escrow Engine manages fund states, the Wallet Service tracks balances, and the Atomic Transaction layer ensures all-or-nothing operations. 7 transaction invariants enforce financial correctness.

API Layer

REST APIExpress.jsRequest validation

Engine Layer

Ledger EngineEscrow EngineWallet ServiceAtomic Transactions

Integrity Layer

Idempotency keys7 transaction invariantsDouble-entry validation

Data Layer

PostgreSQL5 core tablesSupabase

// key decisions

Double-entry bookkeeping

Every financial transaction has two sides — a debit and a credit. Double-entry ensures the books always balance. If they don't, something has gone wrong and the system knows it immediately.

Idempotency keys on all write operations

Networks fail. Mobile apps retry. Without idempotency, a retry means charging twice. Every payment operation accepts an idempotency key — the same key always produces the same result, never a duplicate charge.

Atomic transactions at the database level

An escrow operation touches multiple tables — the buyer's wallet, the escrow hold record, and the ledger entry. If any step fails, all steps must roll back. PostgreSQL transactions enforce this guarantee.

// screenshots

Walking through the product.

System Architecture Card

The technical architecture overview showing the four engine layers, core tables, and transaction invariants. Backend is built; frontend and public release are pending.

// challenges & solutions

What was hard. How I solved it.

Designing financial invariants without a finance background

// problem

Financial systems have strict correctness requirements that general software engineering doesn't prepare you for. Getting them wrong means money disappearing or appearing from nowhere.

// solution

Studied double-entry bookkeeping principles and worked backwards from the invariants — what must always be true regardless of how the system is used. Defined 7 non-negotiable invariants before writing a single line of code.

// outcomes

Working backend — frontend not yet built, no users yet.

Core tables

Schema implemented

Processing engines

Backend logic built

Transaction invariants

Correctness rules enforced

Users

Pre-launch — no frontend yet

The EscrowPay backend is functionally complete — Node.js/Express API, PostgreSQL schema, escrow state machine, wallet service, and idempotency layer are all built and working. The frontend has not been started. No users yet. Next step is building the frontend and integrating with Zolarux as the primary payment backend.

// next steps

What's coming.

→Build the frontend — transaction dashboard and payment UI

→Integrate with Zolarux marketplace as the live payment backend

→End-to-end testing across buyer, vendor, and dispute flows

→Open-source the engine for other Nigerian social commerce platforms

// enjoyed reading this? check out all projects.

← All Projects Work With Me →