StylerStack
Fashion e-commerce API with M-Pesa payments
A fashion marketplace needed to accept mobile money payments reliably — without risking duplicate charges from retried requests or unverified payment callbacks.
- →M-Pesa STK push callbacks can arrive late, out of order, or more than once
- →Vendors, customers, and admins each need different views of the same orders and inventory
- →Catalog browsing needed to stay fast as product and order volume grew
- →Deploys needed to be safe enough to ship without a dedicated ops team
Idempotent Daraja payment flow
Every payment request is issued an idempotency key stored against the order. Incoming Daraja webhooks are signature-verified, then applied as an atomic database upsert keyed on that identifier — so retries and duplicate callbacks settle to a single charge.
Cache-aside catalog reads
Frequently read product and category data sits behind a Redis cache-aside layer, cutting catalog read latency by roughly 40% during testing without weakening consistency for writes.
Role-scoped JWT access
Customer, vendor, and admin roles are encoded in JWTs and enforced via FastAPI dependencies, giving each role its own view of orders and inventory from the same API surface.
CI/CD to Railway
GitHub Actions runs the test suite and builds a Docker image on every push, deploying to Railway so the API ships continuously with a repeatable, auditable pipeline.
- Zero duplicate charges observed across repeated and out-of-order Daraja callbacks
- ~40% reduction in catalog read latency after introducing Redis caching
- Three-role access model (customer/vendor/admin) on a single API surface
- Continuous deployment to Railway via GitHub Actions