CampusPay

CampusPay turns on-time university fee payments and student business sales into verified financial passports with AI underwriting, letting students and campus merchants qualify for microloans.

Comment

Inspiration

University fees are a major financial responsibility for students, but managing individual charges, tracking payments, and keeping reliable financial records can be fragmented. At the same time, student entrepreneurs may struggle to present a clear financial history when seeking support for their businesses.

I built CampusPay around one question: what if managing university fees could do more than record what a student owes? What if it could also help students build a useful financial track record while giving universities better tools to manage collections?

The idea is to connect students, university bursaries, fee sponsors, and student entrepreneurs through one platform designed around the realities of tertiary education in Ghana.

What it does

CampusPay is a fintech platform for university fee management and student financial records.

  • Fee management: Organizes university charges into individual fee obligations, allowing students to view amounts paid, outstanding balances, due dates, and applicable instalment options.
  • Payments and receipts: Includes a payment workflow with Paystack test-mode checkout and transaction verification logic. The project also contains simulated payment records, which are distinguished from verified external transactions.
  • Bursary operations: Provides interfaces for managing fee schedules, monitoring collections, viewing outstanding balances, and reconciling payment records.
  • Student financial profiles: Calculates a rules-based payment-reliability score from fee-payment behaviour and outstanding obligations.
  • Student-business marketplace: Allows users to browse products and services offered by student businesses, with business, product, and sales records stored in the database.
  • AI-assisted funding-readiness analysis: Generates a structured assessment of a student's business using available sales data and, where the student has enabled consent, relevant academic payment information. The report can identify strengths, risks, trends, and possible next steps. It is an advisory assessment, not a loan approval or credit-bureau score.

CampusPay is not a lender. Its longer-term goal is to help students maintain useful financial records and make it easier for universities and potential financial-support partners to assess relevant information responsibly.

How we built it

I built CampusPay using Lovable and developed it into a full-stack TypeScript application.

The frontend uses React 19, TanStack Start and TanStack Router, Tailwind CSS 4, and reusable Radix UI-based components. TanStack Query supports data-fetching workflows, while React Hook Form and Zod support form handling and input validation. Recharts is used for data visualizations.

The backend combines TanStack Start server functions with Supabase authentication and a PostgreSQL database. The database stores student profiles, institutional records, fee schedules, individual obligations, payments, roles, businesses, products, and sales. Database functions, triggers, and row-level security policies support fee assignment, transaction processing, and access control.

Paystack is integrated in test mode for checkout initialization and server-side transaction verification. Payment intents bind a transaction reference to its intended payment details, and the settlement logic is designed to prevent duplicate processing. Test-mode transactions and simulated historical records are not treated as proof of live-money transfers.

For the business funding-readiness report, I integrated the AI SDK with the OpenAI provider through the Lovable AI Gateway. The server loads relevant records subject to access controls and consent before preparing the assessment.

The project also includes versioned SQL migrations and written audit documentation so changes to the financial and authorization systems can be reviewed rather than treated as invisible frontend behaviour.

Challenges we ran into

One of the biggest challenges was moving beyond a convincing interface to a system whose financial records and permissions could be trusted.

First, fee schedules and student records must match consistently. Differences in programme names and academic levels can lead to missing fee obligations or inaccurate balances. This required investigating the actual database relationships and preparing a reviewable reconciliation process.

Second, a payment success screen is not proof that money moved. The system needed a clearer separation between simulated transactions, payment-provider verification, and accounting reconciliation. Duplicate callbacks, incorrect amounts, and failed transactions also have to be handled without corrupting balances.

Third, authentication is not the same as institutional verification. A signed-in user should not automatically receive access to verified student privileges, bursary operations, or another person's financial records. This led to a dedicated authorization audit and changes intended to tighten identity verification, role assignment, institutional boundaries, and database permissions.

Finally, the business funding-readiness feature needed careful boundaries. AI can summarize financial information, but its output must not be presented as a validated lending decision. The quality of the assessment depends on the quality and authorization of the underlying records.

These challenges reinforced the importance of testing database behaviour and authorization rules—not just checking whether the application looks correct in a browser.

What we learned

Building CampusPay taught me to think of fintech as a system of records, permissions, and verifiable events rather than simply a collection of payment screens.

I learned how frontend workflows connect to server functions, relational data models, authentication, row-level security, payment-provider verification, and AI-assisted analysis. I also learned that financial data needs explicit handling for corrections, duplicate events, simulated transactions, and institutional access boundaries.

Most importantly, I learned that adding AI to a financial product is not enough to make it trustworthy. The underlying data must be accurate, access must be controlled, and the output must communicate its limitations.

What's next

The next stage is to complete and verify the security and operational foundations: finish role and institutional-access hardening, reconcile existing fee records, test payment failures and duplicate events, strengthen monitoring and recovery, and validate the main user journeys with controlled test accounts.

Before handling real university payments, CampusPay needs end-to-end testing and operational verification beyond the current test-mode implementation. The longer-term goal is a dependable platform that helps students manage fees and build financial records while giving universities clearer, more accountable financial workflows.

Built With

Share this project:

Updates

Submission history