Back to project
Case Study

TPMS Expertic - TPE Operations Platform Case Study

Public-safe case study for Expertic's Terminal Payment Management System, focused on role-based workflows, architecture, and operational product design.

Overview

TPMS manages electronic payment terminal operations across banks, account managers, clients, tickets, inventory, and support workflows. The public version uses sanitized screenshots and avoids credentials, customer data, and sensitive details.

Problem

TPE operations involve bank requests, account manager coordination, interventions, and traceable inventory changes. Without one role-aware platform, ticket status, stock, attachments, and bank/client data fragment.

Context

The implementation uses a Next.js frontend, NestJS backend, and Prisma/PostgreSQL. It separates account manager and bank employee experiences and covers intervention, consumable, network check, and deblocking workflows.

My Role

Full-stack contributor during the Expertic role. The project is framed as an Expertic contribution, not solo ownership, with focus on implementation, architecture, and workflow design.

Goals

  • Centralize TPE service requests and inventory flows in one authenticated web platform
  • Give bank employees a scoped workspace for creating and tracking requests
  • Give account managers operational control over tickets, banks, clients, TPE models, consumables, and dead stock
  • Keep authorization explicit through JWT authentication, role guards, and CASL policies
  • Support operational handoffs with notifications, attachments, and Excel import/export

Technical Decisions

  • Use Next.js App Router and TypeScript for role-specific dashboard pages and reusable UI patterns
  • Use a central Axios API layer so screens call typed endpoint helpers instead of hard-coded requests
  • Use NestJS route modules split by role and resource, keeping bank employee and account manager APIs explicit
  • Use Prisma with PostgreSQL for the core data model: users, banks, clients, TPEs, terminal types, tickets, attachments, and stock entities
  • Use JWT, global guards, role endpoint checks, and CASL permissions to enforce access at the API layer
  • Use Server-Sent Events for live notification streams and mail templates for operational updates
  • Support attachments and Excel template import/export for real operations work alongside CRUD forms

Architecture

The frontend is a role-aware Next.js dashboard. JWT-backed sessions call typed Axios helpers, then requests flow into role-scoped NestJS modules. Guards and CASL protect tickets, inventory, banks, clients, consumables, dead stock, notifications, attachments, and Excel flows. Prisma persists the model in PostgreSQL.

Architecture Map

Mermaid
flowchart LR
  Bank["Bank employee workspace"] --> Front["Next.js role dashboard"]
  Manager["Account manager workspace"] --> Front
  Front -->|"Axios REST + cookie JWT"| Api["NestJS API"]
  Api --> Guards["JWT guard, role guard, CASL policies"]
  Guards --> Modules["Role scoped API modules"]
  Modules --> Tickets["Ticket workflows: intervention, consumable, network check, deblocking"]
  Modules --> Operations["TPE stock, banks, clients, terminal models, dead stock"]
  Api --> Prisma["Prisma service"]
  Prisma --> Db[("PostgreSQL")]
  Api --> Notify["SSE notifications"]
  Api --> Mail["Email templates"]
  Api --> Files["Attachments + Excel import/export"]

Case Study Screenshots

11 views
Account manager request dashboard with ticket filters, Excel import/export, and new request entry point.
Multi-type request modal for intervention, consumable, network choice, and deblocking workflows.
Bank management surface with search, status filtering, KPI cards, and bank creation.
Create bank modal split into bank information, sub-accounts, and terminal model assignment.
Consumables inventory with stock summaries, search, low-stock filtering, and create action.
TPE catalog grouped by manufacturer, with model details and controlled delete actions.
Account manager dead stock inventory with assignment status, filters, and stock table.
Account manager settings for profile updates and password changes.
Bank employee dashboard with scoped request tracking and simplified navigation.
Bank employee dead stock view with assigned inventory summaries and read-only table flow.
Bank employee settings showing profile controls and linked bank information.

Key Features

  • Account manager dashboard for ticket monitoring, Excel template download, Excel upload, and new request creation
  • Bank employee dashboard with scoped ticket tracking and simplified navigation
  • Multi-tab new request form covering intervention, consumable, network choice, and deblocking workflows
  • Bank management with sub-accounts and TPE model assignment
  • TPE manufacturer/model management with grouped views and detail actions
  • Consumables inventory with stock status and request support
  • Dead stock management for account managers and read-only assigned inventory for bank employees
  • Profile/settings screens for both roles

Challenges

  • Keeping account manager and bank employee capabilities distinct without duplicating every screen and API concept
  • Modeling several ticket types with shared client/bank data but different validation requirements
  • Making dense operational tables searchable and filterable without slowing down day-to-day workflows
  • Handling attachments and Excel workflows alongside normal JSON API calls
  • Presenting the project publicly without exposing private production data or unsupported metrics

Results / Outcomes

  • Produced a full-stack case study with screenshots, a Mermaid architecture map, and implementation-grounded details
  • Covers dashboard work beyond marketing pages: role-aware navigation, data tables, modals, forms, settings, and operational APIs
  • Covers backend architecture with NestJS modules, Prisma, JWT authentication, CASL authorization, notifications, uploads, and Excel workflows
  • Keeps public wording focused on architecture and contribution rather than confidential data or unverified metrics

What I Learned

  • Operational software lives or dies by clear role boundaries and predictable handoffs
  • Ticket systems need flexible shared primitives because each request type has its own validation and lifecycle details
  • Internal work should show architecture, workflows, and sanitized visuals instead of confidential data
  • Small implementation choices like endpoint naming, table filters, and modal state handling matter a lot in admin-heavy tools