[03]
Storefront surface
The storefront includes search, filtering, cart, wishlist, moderated reviews and resumable guest checkout. Promotions are validated server-side for eligibility and value.
[CASE STUDY 05][IN DEVELOPMENT]
WisdomUp Multi-Service E-Commerce Platform
A three-service commerce platform — storefront, transactional API and CMS admin — built around a checkout designed for its edge cases, not just its happy path.
- Role
- Full-Stack Product Engineer
- Timeline
- 2026 – Present
- Status
- In development
- Stack
- Next.js, TypeScript, Express 5 +6
* THREE SERVICES + DUAL SETTLEMENT
[AT A GLANCE]
- ROLE
- Full-stack product engineer across all three services
- OWNED
- Storefront · Express transactional API · Payload CMS admin · the settlement path that runs between them
- SURFACES
- Three independently deployable services over one shared MongoDB
- SCOPE
- Catalogue derived from host and market, so one codebase serves a local and a global storefront
- STATUS
- In development — the payment path is hardened and tested, and has not yet carried production traffic
[STACK]
- Next.js
- TypeScript
- Express 5
- MongoDB
- Payload CMS
- Stripe
- Redux Toolkit
- RTK Query
- Zod
[01] The problem
Checkout breaks in the edge cases
Commerce systems often couple content changes to releases and treat payment callbacks as orderly. Duplicate, delayed or mismatched events then become financial risk, while a monolith makes either concern harder to change safely.
[02] The constraints
What a payment system has to assume
The money settles once; the events describing it do not
Stripe events can be duplicated, delayed or reordered. Every settlement write therefore had to be safe to replay without charging twice or advancing an unpaid order.
A campaign cannot wait for a release
Marketing needed to change banners, FAQs and promotions without engineering releases, while the storefront had to tolerate incomplete CMS data.
Nothing here has production traffic to check it against
The payment controls are tested but not yet proven by production traffic. The case study reports implementation counts, not business outcomes.
[03] The approach
How it was built
I separated storefront, transactional API and CMS, then designed settlement for duplicate and out-of-order events. Money writes are idempotent and the order state machine only advances through explicit transitions.
[KEY DECISIONS]
- [01]Separated the storefront, Express API and Payload CMS into independent deployables over one database.
- [02]Settled payments through immediate confirmation and webhook reconciliation.
- [03]Guarded settlement with verification, idempotency, replay protection and monotonic order state.
- [04]Derived catalogue scope from host and market and enforced it again at checkout.
[04] The trade-offs
Where correctness beat the simpler path
[01]
Settle down two independent paths
- Instead of
- Trust the webhook alone, which is what Stripe's own documentation recommends and is one code path instead of two
- What it cost
- Two writers must be idempotent and agree on what has already happened.
- What it bought
- A closed browser or delayed webhook cannot lose a paid order.
[02]
Order status only moves forward
- Instead of
- Apply whatever the latest event says, which is the obvious reading of an event stream
- What it cost
- Refunds and cancellations need explicit transitions instead of direct status assignment.
- What it bought
- Stale events become no-ops and cannot regress an order that has already advanced.
[03]
Three services over one shared database
- Instead of
- A database per service, which is what service separation is normally taken to mean
- What it cost
- Schema changes require coordination and service isolation is incomplete.
- What it bought
- Checkout avoids distributed transactions while services retain separate deployment and bounded ownership.
[04]
Content is data the CMS owns, not components the repository owns
- Instead of
- Hard-code the sections and ship a release when marketing wants a change
- What it cost
- The storefront needs typed contracts, validation and defensive rendering for optional content.
- What it bought
- Eleven collections plus site settings let marketing publish without an engineering release.
[05] The build
The three services
[01]
Two paths to settled
Client confirmation records payment immediately; the webhook reconciles signature, amount, ownership and transaction identity. Fourteen tests cover this settlement logic.
[02]
Merchandising without a deploy
Eleven CMS collections plus editable navigation and site settings cover merchandising, with CSV import for bulk catalogue work.
[06] The result
What is built — and what is not yet observed
3
Deployable services
* storefront · API · CMS
8
Payment guard layers
* signature to state machine
14
Settlement tests passing
* confirmation logic
2
Independent paths to settled
* client confirmation · webhook fallback
[HOW THESE WERE MEASURED]
These are implementation counts, not production outcomes: three deployables, eight settlement guards, fourteen passing tests and two paths to a settled order. Tests verify the written logic, not its assumptions under live traffic.
[07] What I’d do differently
Honestly
The payment layer is hardened but not yet observed in production. I would instrument checkout success, reconciliation accuracy and promotion conversion before adding more features.
Need something like this built?
Next case study [06]
Muterpe
AI Image Generation SaaS
Read the case study →
