Shreeji

The problem

Shreeji sells computers, power systems and networking hardware in Lusaka, and has done since 1998. Putting that catalogue online is not the hard part. Two things about the business are.

The first is currency. Stock is bought in dollars and sold in kwacha, against a rate that moves, plus 16% VAT. So a price isn't a field someone types. It's the output of a calculation whose inputs keep changing, and every one of those inputs has to be inspectable months later, when a customer asks why the number differs from the quote you gave them last week.

The second is that a Zambian business buyer often doesn't pay with a card. They pay by bank transfer, or they collect and pay on pickup. Either way the order exists and sits unpaid for hours or days. A checkout flow modelled on card-or-nothing has nowhere to put that state.

What I built

Both halves: the NestJS API and the Next.js frontend that serves the storefront, the customer portal and the admin console.

Two parts are worth reading about. The first is the payment abstraction: one gateway interface, with a card path that's only ever confirmed server-side, an asynchronous bank-transfer path with a deadline and a job that enforces it, and a cash-on-pickup path that skips the gateway entirely. The second is the order transaction, which locks the stock it's about to spend instead of trusting a read.

Around those sits an admin console that owns the catalogue, inventory with stock valuation, coupons, loyalty, returns and the site's own page copy, so marketing changes don't need a deploy. Gateway credentials and saved card tokens are AES-256 encrypted at rest, with only the last four digits of a card kept in the clear. Product images run through a background-removal service and land in MinIO rather than the application's filesystem.

Guest checkout can look an order up afterwards without an account, through an endpoint that 404s when the email doesn't match the order. An unauthenticated lookup that answers "wrong email" differently from "no such order" is just an email enumeration oracle with extra steps.

What is still on the roadmap

DPO's card path puts redirect, 3DS and callback in one pass, and no automated suite can exercise that. It needs a live card and an OTP from a real handset. So it clears a manual check rather than a green CI run, and I'd rather say that plainly than blur it. A path covered by tests and a path covered by someone actually running it are different things.

Payment retries and refunds are specified rather than built. Refunds today are a manual reconciliation between the gateway and the order, which is the right call at the volume they happen and the wrong one as that volume grows.

There's also a performance question I'm partway through. The API has been intermittently slow on staging while Postgres itself stayed responsive, which rules out the database and points at the Node process. My money is on event-loop blocking or connection-pool starvation. The next step is per-request tracing to tell those two apart, rather than guessing.