A production-ready member management and payment processing platform built for Brilliant Child College 2007 alumni to manage dues, events, and help-desk operations with real-time updates and secure automated flows.
- Framework: React Router v7 (Framework Mode)
- Styling: Tailwind CSS
- Icons: Lucide React
- Components: UI components based on shadcn/ui
- Client State: TanStack Query & React Context
- Framework: Express.js with TypeScript
- Contract: ts-rest for type-safe API communication
- Database: MongoDB via Mongoose
- Authentication: Better Auth
- Payments: Paystack API
- Background Jobs: Upstash QStash/Workflow
- Real-time: Server-Sent Events (SSE)
The system uses a two-tier onboarding process to ensure all members are verified and have complete profiles.
- Registration: Admins can register members. New members receive a temporary password via email (Upstash QStash).
- First Login: Members log in, verify their email, and complete their profile information.
- Onboarding Checklist:
- Basic Info (Phone, Gender, Location, Occupation)
- Update Profile Avatar (Cloudinary)
- Complete Bank Details (for future payouts or transfers)
- Completion: Once all steps are completed, the
isOnboardedstatus is updated, and the user gains full access to the dashboard.
The core of the application is a secure payment processing engine for dues, event fees, and donations.
- Initialization: A member selects a payment type (e.g., Monthly Dues). The client calls
initializePayment, and the server communicates with Paystack to generate a unique transaction reference and checkout URL. - Processing: The user is redirected to Paystack's secure portal to complete the transaction.
- Verification: After payment, the user is redirected back to
/dashboard/payments/verify. The server then confirms the status with Paystack's API. - Sync & SSE: Once verified, the transaction is recorded in MongoDB. An SSE event (
payment:completed) is broadcasted to all logged-in sessions to update UI stats in real-time.
- Event Creation: Admins create events with descriptions, dates, and optional fees.
- Engagement: Members can mark interest in events.
- Payments: If an event has a fee, members can pay directly through the integrated payment flow.
- Ticketing: Members can create support tickets for technical or payment-related issues.
- Resolution: Admins manage tickets from the dashboard, assigning staff and updating status (Open -> In-Progress -> Resolved).
- Communication: Status updates trigger real-time notifications to the affected member via SSE.
The application maintains a persistent connection (/api/v1/sse/stream) to keep the dashboard alive without manual refreshes.
- Broadcasts include:
payment:completed,ticket:updated,event:created, andmember:created. - These events automatically trigger TanStack Query cache invalidations, ensuring the UI always displays fresh data.
├── client/ # React Router 7 Frontend
│ ├── app/
│ │ ├── components/ # UI & Shared Components
│ │ ├── context/ # Stores & Application State
│ │ ├── features/ # Feature-specific logic (dashboard, payments, etc.)
│ │ ├── routes/ # Page components & layouts
│ │ └── lib/ # Utilities (storage, queryClient)
│ └── public/ # Static Assets
├── server/ # Express.js Backend
│ ├── src/
│ │ ├── config/ # Environment, Auth, & DB Config
│ │ ├── contract/ # ts-rest API definitions
│ │ ├── middleware/ # Security, Rate Limiting, Auth
│ │ ├── models/ # Mongoose Schemas
│ │ ├── workflows/ # Upstash Workflow Jobs
│ │ └── routes/ # API Implementations
│ └── index.ts # Entry Point
- Security Headers: Managed via Helmet with custom CSP policies for Cloudinary and Paystack.
- Rate Limiting: Granular rate implementation for sensitive endpoints (Auth, Payments) using
express-rate-limit. - Validation: Strict input sanitization and typing via Zod across both client and server.
To ensure a high-standard, production-ready codebase, the project follows a strict branching and CI/CD strategy.
main: The production-ready branch. Only merges fromstagingare allowed via Pull Requests.staging: The integration branch. All feature branches and bug fixes must be merged here first for testing.feature/*orfix/*: Temporary branches for new development or patches.
Both main and staging branches are protected to prevent accidental direct pushes and ensure quality:
- Pull Requests (PRs) Required: All changes must go through a PR. Direct pushes to
mainandstagingare blocked. - Status Checks: GitHub Actions must pass (Linting, Typechecking, Unit Tests, E2E Tests) before a merge is permitted.
- Code Reviews:
mainrequires at least 1 approving review from a code owner.stagingrequires a successful PR and passing CI (no manual approval required for solo development speed).
- Admin Enforcement: These rules apply to everyone, including repository owners, to ensure a consistent workflow.
- CI (GitHub Actions): Every PR to
stagingormaintriggers an automated pipeline:- Server: Typechecks and Vitest unit/integration tests.
- Client: Typechecks, Vitest unit tests, and Playwright E2E tests.
- Deployment:
- Merges to
maintrigger a production deployment to Vercel for both client and server applications.
- Merges to
When starting a new task:
- Create a feature branch from latest
staging. - Push changes and open a PR targeting
staging. - Use the provided PR Template to describe your changes.
- Once CI passes and the PR is merged, create a subsequent PR from
stagingtomainfor production release.