Product Manager · Fintech & EdTech

Building payment
products that work
in production.

I spec, scope, and ship end-to-end fintech products — from API payload design to webhook idempotency to role-based dashboards. This portfolio documents two of them in full.

See the case studies → PayPulse Analytics ↓
Scroll to explore
2
Production fintech dashboards shipped
INR+USD
Multi-currency handled in both
3
Orgs served (UNext, SMU, MUJ)
0
Manual reconciliation steps

Payment Link Generator
UNext Learning

A production-ready fee collection tool built end-to-end — from Juspay API integration to real-time webhook handling to role-based analytics.

Payment Link Generator — UNext Learning

A full-stack internal tool that replaced manual, fragmented fee collection with a real-time, role-aware dashboard. Educators generate Juspay payment links in seconds; the system automatically syncs payment outcomes via webhooks — eliminating manual reconciliation entirely.

Role
Product Manager
Domain
EdTech · Payments
Gateway
Juspay
Stack
React · Node.js · PostgreSQL
Real-time
Payment status via webhooks
Unified
Dashboard for all users & orders
Zero
Manual reconciliation post-deploy
4
Full audit log types captured

UNext Learning's fee collection was entirely manual. Operations staff coordinated across email, spreadsheets, and a raw Juspay merchant account — with no unified view of who had paid, which links had expired, and who generated which link.

When a student made a payment, there was no automatic update to internal records. Every payment required a manual check in Juspay's dashboard and a corresponding update to a shared spreadsheet. For a business processing fees across multiple programs, semesters, and currencies (INR and USD), this created significant operational delay and reconciliation errors.

The core question: how do we give educators a fast, reliable way to generate and track payment links — without building a full billing platform from scratch?

I scoped and shipped a focused internal tool: a Payment Link Generator that wraps Juspay's session API in a clean, role-aware interface purpose-built for UNext's fee collection workflow.

Rather than building a generic payment tool, I made deliberate product choices: expiry enforcement mapped to exact minute calculations, semester selection rules tied to fee type (single select for Semester, consecutive-only for Annual and Full Course), automatic gateway routing based on currency (INR → Semester-RD, USD → Semester-RI), and a webhook handler that writes payment outcomes directly into the dashboard — eliminating manual reconciliation entirely.

The app captures structured logs across all four interaction points (user submission, Juspay API call, webhook receipt, SLCM), giving the team full audit visibility without needing to access Juspay's own dashboard.

Why PostgreSQL over a lightweight option like lowdb?
Webhook events arrive asynchronously and must be idempotently matched to orders. A proper relational DB ensures durability and concurrent write safety — critical when multiple payment events can arrive for the same order ID.
Why Admin-only system logs?
API payloads and webhook bodies contain sensitive payment data. Restricting access to the Admin role keeps the operational interface clean for regular users without building a separate admin console.
Why enforce consecutive semester selection?
Annual and Full Course fee types correspond to contiguous academic periods. Non-consecutive selection creates invalid fee structures and downstream reconciliation errors in SLCM. The UI constraint prevents the error at the source.
Why not use Juspay's hosted dashboard directly?
Juspay's dashboard is generic. Our team needed UNext-specific fields (roll number, program, semester, fee type), per-user attribution, and INR/USD routing logic baked into a single workflow — none of which Juspay natively supports.
Why migrate from URL tokens to email/password auth?
URL-based tokens are shareable and unrevokable. Email/password auth with roles gives us proper access control, forgot-password flows, and the ability to restrict sensitive log access to the Admin role only.
🔗

Live Juspay Integration

Full session API with payload mapping, expiry-in-minutes calculation, and currency-based gateway routing (INR → Semester-RD, USD → Semester-RI).

Webhook Handler

ORDER_SUCCEEDED and ORDER_FAILED events. Extracts epg_txn_id, txn_id, status — auto-updates DB in real time with IST timestamp conversion.

📊

Analytics Dashboard

Metrics, per-user breakdown, paginated orders table, 4 live filters, status badges, copy-to-clipboard. Auto-refreshes every 30 seconds.

🔐

Role-Based Auth

Email + password login. Admin sees full system logs. Regular users see only operational views. Forgot-password flow with complexity enforcement.

📋

4-Type Audit Logs

User submissions, Juspay API calls, webhook payloads, SLCM events — each with collapsible JSON and timestamps. Admin-only access.

📱

Semester Validation

Single select for Semester fee type. Consecutive-only dual select for Annual. Consecutive-only multi-select for Full Course. Enforced in UI.

Real-timePayment status visible across the team
🎯UnifiedSingle source of truth for all orders
ZeroManual reconciliation steps post-deployment

Before this tool, a staff member would generate a link in Juspay, note it manually, share it with the student, then check back later to see if it was paid — updating a spreadsheet by hand. Errors and delays were routine.

After deployment: the entire lifecycle — link generation, delivery, payment, status sync — is captured automatically. The operations team has a live dashboard with full visibility into every order, zero manual work required after link generation.

The broader signal: this demonstrates that well-scoped internal tooling can eliminate entire categories of operational overhead without the cost or risk of a full platform rebuild.

Fee Collection Dashboard
PayPulse Analytics

A payment and re-registration analytics platform built for two universities — combining source-data governance with auditable USD→INR conversion and live program-level KPIs.

PayPulse Analytics — SMU & MUJ

A full-stack analytics application that gives finance and academic-ops teams a live view of collected, gross and outstanding fees across programs, batches and semesters — with every USD payment normalized to INR through an auditable, dataset-locked conversion trail instead of a black-box number.

Role
Product Manager
Domain
EdTech · Payments Analytics
Orgs
SMU · MUJ
Stack
React · Vite · Node.js · PostgreSQL
2 Orgs
SMU & MUJ on one platform, isolated datasets
Auditable
USD→INR trail: rate, source, settlement date
Versioned
Archive-before-activate upload governance
Zero
Live rate polling — snapshot locked per dataset

Sikkim Manipal University (SMU) and Manipal University Jaipur (MUJ) run fee collection and re-registration through source systems that produce raw payment exports — but no unified way to see collected vs. gross vs. outstanding fee value across programs, batches and semesters, or to trust a USD-to-INR figure without knowing which rate produced it.

USD payments in particular were a problem: a single converted number hides the question finance actually asks — which rate, on which date, under which banking-calendar rule, produced this INR figure? Without that trail, discrepancies were hard to explain and harder to audit.

The core question: how do we give both universities one analytics platform that's safe to hand real financial decisions to — where every uploaded file, every conversion and every edit is governed and traceable?

I scoped and shipped PayPulse Analytics as a single React + Node/Express application serving both organizations from isolated active datasets, with a data governance model borrowed from financial systems: every uploaded CSV is validated and archived immutably first, and only affects live analytics once explicitly activated via Replace or Append — so a bad upload can never silently corrupt a dashboard finance is already relying on.

For currency, I designed a reference-date and settlement-date priority chain (last installment date → own-term date → prior-semester date → record creation date → explicit fallback) feeding a rate lookup that prefers an exact historical Google Finance rate, falls back to the nearest prior market date, then a user override, then a static ₹84 floor — with every one of those decisions exposed in the UI, not hidden in a calculation.

Because Autoscale deployments can cold-start, I made the conversion snapshot dataset-locked: Google Finance and RBI holiday data are only polled at activation time and persisted, so opening the dashboard, applying filters or exporting never triggers an external call or a silently-shifting number.

Why lock the FX snapshot to dataset activation instead of a live refresh?
A number that can change between two views of the same dashboard is unauditable. Polling Google Finance and RBI only at Replace/Append and persisting that snapshot means every figure traces back to one fixed, dated rate history — and the API explicitly rejects manual refresh attempts rather than allowing an inconsistent one.
Why archive uploads before they can ever go live?
Finance teams needed a bad file to be a non-event, not an incident. Every CSV is validated and stored as an immutable archived object first; it only reaches analytics through an explicit activation step, which also means any prior archive can be re-activated as a rollback.
Why give Replace and Append different validation rules instead of one "upload" action?
They carry different risk. Replace swaps the whole active dataset and only needs a stale-write guard. Append merges into live data and must additionally reject already-active files and ambiguous or duplicate payment identifiers — collapsing them into one action would have hidden that Append needs stricter identity checks.
Why scope the approved-program allowlist to SMU only?
SMU has a fixed set of approved programs that MUJ doesn't share. Applying one global allowlist would either hide legitimate MUJ programs or let unapproved SMU programs leak into official totals — org-scoped visibility rules keep both correct.
Why show the full conversion audit trail instead of just the converted amount?
A finance stakeholder questioning a number needs to see the rate, its source and date, the T+1 settlement date and RBI calendar used, and whether a fallback applied — surfacing that inline is what makes the dashboard usable as a source of truth rather than a black box they'd need to double-check elsewhere.
🗂️

Upload Governance

Select org → upload CSV via signed URL → validate headers/rows → archive immutably → explicit Replace or Append activation.

💱

USD→INR Audit Engine

Reference-date priority chain, T+1 banking settlement against RBI city calendars, Google Finance historical rates, and a static fallback — every step exposed per record.

📊

KPIs & Program Analysis

Configurable KPI tiles, sortable program-wise breakdown table, and six chart types (trend, batch, semester, top programs, status, benefit category).

🎓

Learner Records & Detail

Server-side paginated table with debounced search, drag-to-reorder columns, and a per-learner detail panel with full payment and USD audit history.

✏️

Source Record Maintenance

Search, edit, soft-delete and restore individual source rows — scoped to the active dataset version, never touching the original archived file.

📤

Exports

Filtered learner CSV with formula-injection neutralization, plus a program-summary XLSX with totals, autofilter and embedded conversion notes.

🏛️Two orgs, one platformSMU and MUJ analytics on isolated active datasets
🔍Auditable FXEvery USD figure traces to a dated rate and settlement rule
🛡️Governed uploadsBad files never reach analytics before explicit activation

Before this, checking collection health per program meant pulling raw exports and reconciling USD payments by hand, with no consistent record of which exchange rate had been used. There was no safe way to try a new source file without risking the live dashboard.

After deployment: both universities view live, filterable KPIs and program breakdowns from a shared platform, every USD-derived number carries its own audit trail, and new data only goes live through an explicit, reversible activation step.

The broader signal: the same discipline that makes a payment tool trustworthy — governance before automation, and traceability before convenience — applies just as much to analytics as it does to transactions.

From gap to
production

How this project went from a spreadsheet problem to a live payment tool.

Discovery
Identified the ops gap
Mapped the existing process — Juspay account, manual link sharing, spreadsheet reconciliation. Identified where automation would have highest leverage: the status sync loop between payment and record update.
Scoping
Defined the exact API payload mapping
Translated UNext's business fields (roll number, program, semester, fee type) into Juspay's session API schema. Designed the gateway routing rule, expiry calculation logic, and semester selection constraints before writing a line of code.
Build
Shipped full-stack with webhook handling
React frontend, Express backend, PostgreSQL for orders and logs. Webhook handler updates records in real time. Auth migrated from URL tokens to role-based email/password login.
Iteration
Refined based on real usage
Added consecutive semester validation, PaymentID column in dashboard, full country code list via libphonenumber-js, and Admin-only log access — all driven by actual ops team feedback post-launch.
"The key PM skill here wasn't just knowing what to build — it was knowing what not to build. I didn't try to replicate Juspay's full functionality. I built exactly what the team needed, no more."
— Kshitiz Raj Srivastava, on scoping decisions

What I bring to
fintech roles

Payment Integrations

Juspay Razorpay Webhook design Session API Gateway routing Idempotency

Product Management

Spec writing Scoping Tradeoff decisions Stakeholder comms 0→1 builds Internal tooling

Technical Depth

React Node.js PostgreSQL REST APIs Auth design Production deploy

Domain Knowledge

EdTech Fee collection Multi-currency INR / USD Real-time systems

UX & Design

Mobile-first Responsive UI Role-based views Dashboard design Audit logs UX

Ops & Analytics

Metrics dashboards Audit trail design IST timezone handling Pagination & filters

Let's talk
payments.

I'm looking for fintech and product roles where payment integrations and real-time systems are core. If that's your team, I'd love to connect.

Payment Link Generator

Real Juspay integration, live webhook handling, role-based dashboard.

https://payment-gateway-hub--krs08.replit.app/ Open live demo →

PayPulse Analytics

Fee collection dashboard with auditable USD→INR conversion, live for SMU and MUJ.

https://paypulse-unext.replit.app/ Open live demo →