← Back to Projects

PROJECT 07 / 07

FixService Payment — Frontend

A production-grade Next.js 16 frontend for the FixService home-services marketplace — role-based dashboards, Stripe Checkout, and a "job docket" visual language modeled on the real booking lifecycle.

SERVICE BOOKING #FX-0042 · Plumbing Repair Technician: Accepted Customer → Book → Pay Now PAID Stripe Checkout /payment/success

Overview

This is the client for the FixService home-services marketplace — the frontend counterpart to the FixService Payment backend. Its visual identity is a "job docket": every service, booking, and technician card is styled like a paper work order, with stub notches, dashed tear-lines, and mono-font status stamps that echo the product's real booking lifecycle from request to payment.

Brief Description

Built on Next.js 16's App Router with route groups for auth, dashboards, and public pages, each keeping its own private _actions and _components folders. Authentication and authorization are centralized in a single proxy.ts file (Next.js 16's renamed middleware, now running on the Node runtime), managing access and refresh tokens for three distinct roles — customer, technician, and admin — each with its own dashboard. Every form runs through React Hook Form and Zod validation with inline errors, mutations report their state through Sonner toasts, and the payment flow hands off to Stripe Checkout: a customer books a service, the technician accepts, the customer pays, and Stripe redirects back to a success or cancel page that reconciles the booking status server-side.

Challenges Faced

Centralizing every auth and authorization decision in one proxy.ts file meant handling access-token and refresh-token rotation correctly across Server Components and Server Actions without leaking logic into individual pages. Structuring a large App Router codebase — three route groups, each with private actions and components — took discipline to keep decoupled while still sharing types and a common backend-fetch wrapper. The Stripe Checkout handoff was its own challenge: booking → accept → pay → redirect → server-side confirmation had to stay consistent even when a customer abandoned checkout, without leaving a booking stuck in a broken state. Keeping three very different dashboards (customer, technician, admin) visually consistent while each pulled from a different slice of the backend API was the last recurring challenge.

Potential Improvements & Future Plans

Planned next: real-time notifications, live chat between customer and technician, AI-based technician recommendations, Google Maps and location-aware search, deeper review and rating analytics, an interactive admin analytics dashboard, multi-language support, email/SMS notifications, and generated invoices/receipts.

Backend, Docs & Demo Access

This frontend consumes the FixService Payment backend API directly (mapped under /api). Full endpoint documentation is on Postman, and a demo video walks through the booking and payment flow end-to-end.

→ Backend API → Postman API Docs (optional) → Demo Video

Demo Admin Access

Email: mustafiz@admin.com

Password: mustafiz12345