Check the signed-in user
- What
- Payment submission requires authentication.
- Why
- Collection actions must be associated with an authorized account.
- How
- The API checks the user, active retailer record and PIN before processing the request.
TelePoint
EMI management and customer payment collection platform built from retail financial workflow analysis.
01 / The Problem & Analysis
Offline device retailers face payment disputes, cash reconciliation delays, and customer account leakage when tracking installment payments manually.
02 / Engineering & BA Role
Full-Stack Software Engineer (Sole Developer)
03 / Outcome
Customer-to-retailer ownership checks authorize payment collection requests.
Overview
TelePoint is an EMI management portal engineered after analyzing real-world offline smartphone financing friction: payment leakage, cash reconciliation delays, and customer account disputes. It structures collection workflows into authenticated, role-separated stages.
What I built
Modeled retailer-to-customer debt cycles, designed the verification state machine, and implemented customer ownership validation in Next.js and PostgreSQL.
Product Interface
telepoint-topaz.vercel.app
Live
Engineering Decisions
Check customer ownership
- What
- A retailer can submit payments for their own customers.
- Why
- Customer records and collection actions must follow account permissions.
- How
- The route compares the customer’s retailer ID with the authenticated retailer.
Validate installment payments
- What
- The API checks installment status before recording a request.
- Why
- An already paid installment or pending request needs a clear response.
- How
- The route checks the selected installment records and returns errors for unsupported actions.
Connect records to reports
- What
- Customer, installment and payment records support reporting.
- Why
- Collection workflows need a way to review their recorded activity.
- How
- The application reads the related PostgreSQL records for its reports.
Data Architecture & Schema
PostgreSQL stores customer accounts, installment schedules and payment records. Customers are related to retailers, and installments belong to customers. Those relationships support account access checks and reporting.
customer_id- UUID · Unique customer account foreign key
retailer_id- UUID · Authorized device retailer identifier
device_model- TEXT · Financed smartphone or hardware model
total_financed- NUMERIC · Principal device loan amount
installment_count- INT · Total agreed payment schedule (months)
due_date- TIMESTAMPTZ · Monthly payment deadline
status- TEXT · active / paid / disputed / delinquent
payment_method- TEXT · UPI / Cash / Bank transfer verification
API & System Workflow
POST /api/payments/submit checks required fields, authentication, retailer status and customer ownership. It checks the selected installments before creating a payment request. Invalid or conflicting requests receive an error response.
- Authentication
- Retailer Boundary
- Customer Ownership
- Installment Check
- Payment Record
- Reporting
End-to-end system lifecycle
Representative Implementation
Payment authorization · Customer ownership & installment verification. Excerpt from the repository source.
const { data: custOwner } = await svc
.from('customers')
.select('id, retailer_id')
.eq('id', customer_id)
.single();
if (!custOwner || custOwner.retailer_id !== retailer.id)
return NextResponse.json(
{ error: 'Customer does not belong to your account' },
{ status: 403 }
);Interface & Features
The real sign-in screen is shown here. Customer and collection screens require an authorized account.
- Role-based access
- Customer and installment records
- Payment workflow handling
- Database-backed reporting
Technology Stack
- Next.js
- TypeScript
- PostgreSQL
TypeScript · Next.js · PostgreSQL · Authentication · Role-based access · API development · Payment workflow handling · Reporting