Jastip Order & Payment Tracking System

Jastip Order & Payment Tracking System

This system tracks orders and payments for a jastip (personal-shopping) business, replacing WhatsApp chats and a spreadsheet. A jastip business takes pre-orders for a bazaar or a trip, then buys everything on-site. It still has to collect payment and ship parcels to every customer who ordered.

Challenge

Every bazaar run meant dozens of customer orders, each with several items. Everything was tracked across a chat thread and a spreadsheet that got overwritten as often as it got updated. Payment screenshots got buried between order messages. There was no reliable way to see who'd actually paid.

Not every item found at a bazaar is available; some sell out before the buyer gets to them. That changes what a customer owes, and the spreadsheet couldn't handle it on its own. Someone also had to collect a shipping address per customer, track who hadn't sent one, and know who was owed a refund. None of this had dedicated staff; it had to run as a manual workflow one person could keep up with.

Solution

I built a type-safe Next.js and Hono monorepo on Drizzle ORM over SQLite. Hono RPC gives the frontend a typed client straight from the API. An admin creates an invoice per customer, optionally attached to an event, and adds line items with photos. That returns a unique, unguessable link — two concatenated cuid2 strings — to share over WhatsApp, no customer account required.

The customer opens the link and sees the itemized order and bank transfer details. They upload a payment proof photo and fill in their own shipping address on the same page.

Each order moves through a five-state flow: new, processing, shipped, done, or cancelled. Item-level status (ordered, available, or failed to source) is tracked separately. Payment status is computed from item paid timestamps, shipping cost, and any refund, not stored as its own field. That way it can't drift out of sync with what customers actually paid.

Once an item is marked paid, its price and quantity lock server-side. Once shipping cost is marked paid, that number locks too. Once an order ships, the address locks, so a courier already carrying the package can't be sent to a different one.

Payment proof uploads are append-only: a second upload adds to the list instead of replacing the first. Uploads are also rate-limited to prevent abuse. Unit tests cover the payment-balance logic, and end-to-end tests cover both the admin and customer flows.

The admin dashboard recaps activity per event: order count and total order value. It also flags orders still unpaid, orders missing an address, orders needing a shipping cost, and orders owed a refund.

Impact

The business moved from scrolling a WhatsApp thread and cross-checking a spreadsheet to a single dashboard. That dashboard shows unpaid orders, missing addresses, and pending refunds at a glance, filterable per bazaar.

Locking paid items, paid shipping cost, and shipped addresses removed a recurring source of disputes over who changed what after the fact. Append-only payment proofs mean a customer's transfer screenshot never quietly disappears when a second one comes in.