DEV Community: Shitanshu Jha

🚀 Building the ShopEase Admin Dashboard — Challenges, Solutions & What I Learned By Shitanshu Jha

Shitanshu Jha — Wed, 26 Aug 2026 06:26:59 +0000

While developing ShopEase, my goal was not just to create a basic e-commerce website. I wanted to build it as a complete application while learning how real-world Java backend systems are designed.

I am currently developing ShopEase as a full-stack e-commerce application using Java, Spring Boot, Spring Data JPA, Hibernate, MySQL, HTML, CSS and JavaScript.

One of the major milestones in this journey was Module 23 — Admin Dashboard.

The dashboard started as a simple admin page, but gradually became a proper management system for products, users, orders, order statuses and inventory.

🛠️ What I Built

The ShopEase Admin Dashboard currently provides:

📊 Dashboard statistics
📦 Product Management
👥 User Management
🛒 Order Management
🔄 Order Status Management
📋 Inventory Management
⚠️ Low Stock Alerts
❌ Out-of-Stock Alerts
🕐 Recent Orders

The dashboard communicates with my Spring Boot backend through REST APIs and retrieves the required data from MySQL using Spring Data JPA.

😵 The Challenges I Faced

Building the dashboard wasn't as straightforward as I initially expected.

The biggest challenges were not creating the HTML cards or buttons. The difficult part was making sure that the frontend, backend, database and business logic were all connected correctly.

Calculating Dashboard Statistics

Initially, the dashboard needed to display information such as:
Total Products
Total Users
Total Orders
Total Revenue

The challenge was deciding where these values should actually come from.

Instead of calculating everything on the frontend, I implemented the logic on the backend.

For example, product and user counts are retrieved using repository operations:

productRepository.count();
userRepository.count();

Similarly, total revenue required a database query that considers only confirmed orders.

This taught me an important lesson:

Dashboard statistics should come from reliable backend data rather than being calculated or trusted on the client side.

Implementing Inventory Alerts

One of the more interesting parts was implementing inventory monitoring.

I wanted the dashboard to show:

Low Stock
Out of Stock

I implemented repository queries such as:

long lowStockProducts =
productRepository.countByStockBetween(1, 10);

long outOfStockProducts =
productRepository.countByStock(0);

This allowed the backend to directly determine the inventory status.

The dashboard could then display something like:

⚠️ Low Stock 13

❌ Out of Stock 1

This was a good example of how a simple UI feature actually requires proper backend and database logic behind it.

Fetching Recent Orders

Another requirement was displaying the latest orders on the Admin Dashboard.

Instead of returning every order and filtering it on the frontend, I created a repository-level query to retrieve recent orders.

The backend then converts the Order entities into a dedicated DTO:

AdminRecentOrderDTO

The response contains information such as:

Order ID
Customer name
Total amount
Order status
Order creation time

This helped me understand why DTOs are useful when exposing database entities through APIs.

Connecting Everything Through a Dashboard Service

I didn't want the controller to contain all the dashboard business logic.

So I created:

AdminDashboardService

The service is responsible for collecting:

Products
Users
Orders
Revenue
Inventory
Recent Orders

and combining them into:

AdminDashboardResponseDTO

This gave me a much cleaner architecture:

Frontend
↓
Controller
↓
Service
↓
Repository
↓
MySQL

Working through this helped me understand the importance of separating responsibilities instead of putting everything inside one class.

🐛 Debugging Was a Major Part of the Work

One thing I learned while developing ShopEase is that writing code is only half the job.

A lot of my time went into debugging.

For example, I encountered issues where repository methods were not recognized correctly, constructors didn't match DTO parameters, and entity fields differed from what the service expected.

There were also situations where the dashboard displayed incorrect inventory numbers.

Instead of randomly changing code, I started checking the complete flow:

Database
↓
Repository
↓
Service
↓
DTO
↓
Controller
↓
API Response
↓
Frontend

That approach made debugging much easier.

📊 Testing the Dashboard

After implementing the features, I tested the dashboard with actual application data.

For example, the backend returned dashboard information similar to:

Total Products: 58
Total Users: 9
Total Orders: 21
Total Revenue: 7798
Low Stock Products: 13
Out of Stock Products: 1

I also tested inventory changes by changing product stock values in the database and verifying that the dashboard updated accordingly.

This helped confirm that the values weren't hardcoded and were actually coming from the database.

🔐 Admin-Specific Functionality

Another important part was making sure that administrative functionality was separated from normal user functionality.

ShopEase already has role-based behavior for:

USER
ADMIN

The Admin Dashboard is therefore intended for administrative operations such as:

Managing products
Managing users
Managing orders
Updating order status
Monitoring inventory

This made me think more seriously about authorization and access control, rather than treating an admin page as just another frontend page.

🚀 From Admin Page to Production-Ready Module

The biggest takeaway from this module is that a dashboard isn't just a collection of cards.

A proper admin dashboard requires:

UI
+
REST APIs
+
Business Logic
+
Database Queries
+
DTOs
+
Validation
+
Authorization
+
Error Handling
+
Testing

That is what made this module much more valuable for me than simply designing an admin interface.

🧠 What I Learned

While working on this module, I learned and practiced:

Spring Boot service-layer architecture
Spring Data JPA repository queries
DTO-based API responses
Database aggregation
Inventory management logic
Order management
Role-based functionality
Debugging backend/frontend integration
API testing
Separating business logic from controllers
Designing features around actual application data

More importantly, I learned that production-ready development is mostly about handling the problems that appear between different parts of the system.

👨‍💻 About Me

I'm Shitanshu Jha, a BCA student and developer currently building ShopEase as a hands-on project to strengthen my skills in Java backend and full-stack development.

Instead of only learning technologies theoretically, I'm trying to understand them by building a complete application step by step.

With ShopEase, I'm working with:

Java
Spring Boot
Spring MVC
Spring Data JPA
Hibernate
MySQL
REST APIs
JWT
Spring Security
HTML
CSS
JavaScript
Git & GitHub
Postman

ShopEase is still an ongoing project, and I'm continuing to improve it module by module.

The objective isn't simply to finish another college project.

I'm using ShopEase to understand how real software is designed, debugged, tested and gradually made production-ready.

🚀 What's Next?

With the Admin Dashboard completed, ShopEase has moved into Phase 6 — Production Ready.

The next focus is improving the application's production-level capabilities, including:

Logging
Better error tracking
Reliability
Security improvements
Performance
Deployment considerations

There is still a lot to build, but every module is teaching me something that a tutorial alone couldn't.

ShopEase is not finished yet — and that's the point.

Java

Spring Boot

Backend Development

Full Stack Development

Web Development

I Integrated Razorpay Payments into My Java Spring Boot E-Commerce Project — Challenges, Bugs, and What I Learned

Shitanshu Jha — Sun, 23 Aug 2026 12:13:24 +0000

💳 Integrating Razorpay Payment Gateway into My Java Spring Boot E-Commerce Project

Building an e-commerce application is not just about displaying products and adding them to a cart.

At some point, the application needs to handle one of the most important parts of the entire flow:

Payments.

While working on my ShopEase, a full-stack e-commerce application built with Java Spring Boot, MySQL, JavaScript and JWT authentication, I recently implemented Razorpay Test Mode payments.

The implementation looked straightforward at first:
Checkout
↓
Create Order
↓
Create Razorpay Order
↓
Open Razorpay Checkout
↓
Verify Payment
↓
Confirm Order
But in practice, there were several problems that I had to debug and solve.

This post documents what I actually implemented, the problems I faced, and what I learned from them.

🛒 About ShopEase

ShopEase is my full-stack e-commerce project.

Tech Stack

Frontend

HTML
CSS
JavaScript
Fetch API
LocalStorage

Backend

Java
Spring Boot
Spring MVC
Spring Data JPA
Hibernate
Spring Security
JWT
BCrypt

Database

MySQL

Payment Gateway

Razorpay

Tools

Eclipse
Postman
XAMPP
Git
GitHub

Before implementing payments, I already had:

User authentication
JWT authorization
Product system
Shopping cart
Wishlist
Checkout
Order creation
Order history

So the next logical step was integrating payments.

🎯 What I Wanted to Build

I didn't want Razorpay to simply open a payment popup.

I wanted a complete payment lifecycle.

The final architecture became:
User
↓
Cart
↓
Checkout
↓
POST /orders
↓
ShopEase Order Created
↓
POST /payments/create
↓
Razorpay Order Created
↓
Razorpay Checkout
↓
Payment
├── SUCCESS
│ ↓
│ Verify Signature
│ ↓
│ Payment = SUCCESS
│ ↓
│ Order = CONFIRMED
│ ↓
│ Cart Cleared
│
└── FAILURE
↓
Payment = FAILED
↓
Order = PENDING
↓
Cart Preserved
This distinction between ShopEase Order and Razorpay Order was one of the most important concepts I learned during the implementation.

🧩 Step 1 — Creating a Razorpay Order

I created a backend endpoint:
POST /payments/create
The frontend sends:

orderId
amount

The backend first finds the ShopEase order.

Then I validate that the payment amount matches the actual order amount.

if (!order.getTotalAmount().equals(amount)) {
throw new RuntimeException(
"Payment amount does not match order amount"
);
}

I then convert the amount into paise:

int amountInPaise =
(int) Math.round(amount * 100);

and create the Razorpay order.

The Razorpay order ID is then stored in my Payment entity.

This gives me a relationship like:

ShopEase Order
↓
Payment
↓
Razorpay Order ID
🔐 Step 2 — Payment Verification

One of the most important parts of the integration was payment verification.

After successful payment, Razorpay provides:

razorpay_order_id
razorpay_payment_id
razorpay_signature

I send these values to:

POST /payments/verify

The backend constructs the signature payload:

String payload =
razorpayOrderId
+ "|"
+ razorpayPaymentId;

Then I verify the signature using the Razorpay secret:

Utils.verifySignature(
payload,
razorpaySignature,
System.getenv("RAZORPAY_KEY_SECRET")
);

I deliberately kept the secret on the backend instead of exposing it in JavaScript.

🐛 Challenge 1 — Order ID Was Missing

This was one of the first real bugs I encountered.

The frontend initially expected the order response to directly contain the order ID.

But my backend response was wrapped inside my standard:

ApiResponse

The actual response structure was effectively:

{
"success": true,
"message": "Order placed successfully",
"data": {
"orderId": 14,
"totalAmount": 4299
}
}

My frontend initially wasn't extracting the nested data correctly.

This resulted in:

Order created but Order ID was not received.

I debugged it by printing the raw response:

console.log(
"RAW ORDER RESPONSE:",
JSON.stringify(order, null, 2)
);

The response showed me that I was reading the wrong level of the JSON structure.

I fixed the API layer so that placeOrder() returns:

return {
orderId: order.orderId,
totalAmount: order.totalAmount
};

This was a good reminder that frontend/backend integration bugs are often response-contract bugs, not business-logic bugs.

🐛 Challenge 2 — Razorpay Was Not Opening Reliably

Another confusing problem was that Razorpay sometimes didn't open when I clicked Place Order from the cart flow.

But when I manually opened Checkout.html, it worked.

I initially suspected Razorpay itself.

The actual problem was in my application flow and state handling around the cart/checkout page.

I traced the complete flow instead of assuming the payment gateway was broken:

Cart
↓
Checkout
↓
Create Order
↓
Create Razorpay Order
↓
Open Razorpay

This debugging process helped me separate:

application bugs

from

payment gateway bugs.

That distinction saved a lot of time.

🐛 Challenge 3 — Payment Failed But Database Still Had CREATED

This was a more important backend problem.

When a Razorpay payment failed, I initially had a record like:

Payment
Status = CREATED

even though the user had already failed the payment.

That meant my database wasn't representing the actual payment state.

I implemented a failure endpoint:

POST /payments/fail

and added logic to update the payment:

payment.setStatus(
PaymentStatus.FAILED
);

paymentRepository.save(payment);

The frontend listens for Razorpay's failure event:

razorpay.on(
"payment.failed",
async function(response) {
...
}
);

and records the failure on the backend.

After that, my database correctly reflected:

Payment → FAILED
🐛 Challenge 4 — Failed Payment Was Clearing My Cart

This was probably the most important business-logic issue I encountered.

Initially, the order creation flow deleted cart items immediately after creating the order.

That produced this problem:

Cart
↓
Create Order
↓
Cart deleted ❌
↓
Payment
↓
Payment FAILED

Now the customer had paid nothing, but their cart was already empty.

That's bad e-commerce behavior.

✅ The Solution — Clear Cart Only After Successful Payment

I changed the flow so that creating an order does not immediately delete the cart.

Instead:

Order Created
↓
Payment Created
↓
Razorpay Payment

Only after successful payment verification:

Payment SUCCESS
↓
Order CONFIRMED
↓
Cart Cleared

The backend finds the user's cart:

Cart cart =
cartRepository
.findByUser(order.getUser())
.orElse(null);

Then retrieves its items:

List cartItems =
cartItemRepository
.findByCart(cart);

and deletes them only after successful payment.

This gives the correct behavior:

Successful payment
Payment = SUCCESS
Order = CONFIRMED
Cart = EMPTY
Failed payment
Payment = FAILED
Order = PENDING
Cart = PRESERVED
🧠 Challenge 5 — Java Method/Brace Error

While modifying PaymentService, I also introduced a simple but annoying Java structure error.

I accidentally placed:

markPaymentAsFailed()

inside:

verifyPayment()

because a closing brace was missing.

The compiler then highlighted:

return true;

which initially made it look like return true itself was the problem.

The actual issue was the method structure.

The correct structure is:

verifyPayment() {
...
return true;
}

markPaymentAsFailed() {
...
}

This was a small bug, but it reinforced an important debugging lesson:

When Java highlights a perfectly valid line, don't automatically assume that line is the real problem. Check the surrounding structure first.

🔄 Final Payment Flow

After fixing these issues, the complete flow became:

             SHOP EASE
                 │
               Cart
                 │
             Checkout
                 │
          Create Order
                 │
          MySQL Order
                 │
      Create Razorpay Order
                 │
         Razorpay Checkout
             /       \
            /         \
       SUCCESS       FAILURE
          │              │
   Verify Signature      │
          │              │
    Payment SUCCESS  Payment FAILED
          │              │
   Order CONFIRMED   Order PENDING
          │              │
     Clear Cart     Keep Cart

🧪 Testing

I tested both important scenarios.

Successful Payment

Result:

Order ID: 20
Status: CONFIRMED
Total: ₹3499
Payment: SUCCESS
Cart: Cleared
Failed Payment

Result:

Payment: FAILED
Order: PENDING
Cart: Preserved

This was important because testing only successful payments would have hidden the cart-loss bug.

🔒 Security Considerations

I also made sure that sensitive payment information wasn't trusted blindly from the frontend.

The backend:

Validates the order amount
Creates the Razorpay order
Stores the Razorpay order ID
Verifies the Razorpay signature
Keeps the Razorpay secret on the backend
Updates payment status on the backend
Updates order status only after successful verification

The frontend is responsible for initiating the checkout experience, but the backend is responsible for trusting and recording the payment result.

📚 What I Learned

The biggest lesson wasn't actually how to call the Razorpay API.

It was understanding that payment integration is a state-management problem.

A payment can move through states like:

CREATED
↓
SUCCESS

or:

CREATED
↓
FAILED

And the order has its own state:

PENDING
↓
CONFIRMED

These states need to remain consistent.

I also learned:

Never clear a cart before payment succeeds.
Always verify payment on the backend.
Don't expose payment secrets in frontend code.
Debug the complete frontend → API → service → database flow.
API response structure matters as much as business logic.
Always test failure scenarios, not just the happy path.
Payment integration is tightly connected to order and cart state.
🚀 What's Next?

Razorpay completes another major part of ShopEase.

The next areas I want to work on are:

Admin Dashboard
User Management
Inventory Management
Automated Testing
Pagination
Sorting
Advanced Search
Docker
CI/CD
Deployment

Eventually, I want to take ShopEase from a learning project toward a more production-oriented architecture.

🎯 Final Thoughts

Implementing Razorpay wasn't just about adding a payment popup.

The real challenge was making sure that:

Payment
↕
Order
↕
Cart

all remain consistent.

The bugs I encountered—missing order IDs, incorrect response handling, failed payment state, cart deletion and Java method structure issues—were actually more valuable than simply getting the first successful payment.

That's what made this implementation useful as a development experience.

ShopEase now has a complete tested payment flow using Razorpay Test Mode, with backend verification, payment status tracking, order confirmation, failure handling and correct cart behavior.
ShopEase -Shitanshu Jha

java #springboot #razorpay #ecommerce #webdev

Building ShopEase: My Journey From a Basic E-Commerce App to a Spring Boot Backend

Shitanshu Jha — Sat, 22 Aug 2026 02:33:38 +0000

Building ShopEase: My Journey From a Basic E-Commerce App to a Spring Boot Backend

By Shitanshu Jha

**👋 Hi, I'm Shitanshu Jha

I'm a BCA student and Java Developer focused on backend development and building real-world applications with Java, Spring Boot, REST APIs, MySQL, and Spring Security.**

I'm currently pursuing my Bachelor of Computer Applications at Guru Gobind Singh Indraprastha University (GGSIPU). While learning software development, I wanted to move beyond small practice programs and understand how a complete application is actually designed, connected, secured, tested, and developed over time.

That's what led me to build ShopEase.

ShopEase is a full-stack e-commerce application that I'm developing module by module, starting from basic product management and gradually adding authentication, authorization, cart management, wishlist, checkout, orders, and payment integration. The project currently has a Java/Spring Boot backend, JavaScript frontend, MySQL database, JWT authentication, role-based authorization, and several integrated modules.**

How I built and evolved a full-stack e-commerce application using Java, Spring Boot, MySQL, JavaScript, JWT authentication, and REST APIs.
When I started building ShopEase, my goal wasn't to create a perfect e-commerce application from day one.

I wanted to understand what actually happens behind a real application — how the frontend communicates with a backend, how data is stored, how authentication works, how users are authorized, and how different features come together into one system.

ShopEase started as an e-commerce project and gradually evolved into a much larger full-stack application.

Today, it has a Java + Spring Boot backend, a JavaScript frontend, MySQL database integration, JWT authentication, role-based authorization, persistent cart and wishlist functionality, checkout and order management, validation, DTOs, and centralized exception handling.
🛠️ Tech Stack
Frontend
HTML
CSS
JavaScript
Fetch API
LocalStorage
Backend
Java
Spring Boot
Spring MVC
Spring Data JPA
Hibernate
Spring Security
JWT
BCrypt
Jakarta Validation
Database
MySQL
Tools
Eclipse
Postman
XAMPP
Git
GitHub
🏗️ The Architecture

The basic architecture of ShopEase looks like this:

                ShopEase
                   │
      ┌────────────┴────────────┐
      │                         │
  FRONTEND                   BACKEND
      │                         │
HTML / CSS / JS            Spring Boot
      │                         │
  Fetch API               Spring MVC
      │                         │
   api.js               Spring Security
      │                         │
      └────── REST API ─────────┘
                   │
                  JWT
                   │
                 MySQL

The frontend communicates with the Spring Boot backend through REST APIs, while authentication is handled using JWT.

📦 1. Building the Product System

The product module was one of the first major parts of ShopEase.

On the frontend, I implemented product cards containing information such as:

Product image
Name
Brand
Description
Price
Old price
Discount
Rating
Stock status
Add to cart
View details

On the backend, the product system includes:

Product Entity
Repository
Service
Controller
MySQL integration
JPA/Hibernate
CRUD operations
DTOs
Validation
Exception handling

The main REST APIs are:

GET /products
GET /products/{id}
POST /products
PUT /products/{id}
DELETE /products/{id}

The data flows from the frontend through the Fetch API to the controller, service, repository and finally MySQL before returning a JSON response to the frontend.

🔐 2. Authentication with Spring Security and JWT

This was one of the more important parts of the project.

I implemented:

User registration
Login
BCrypt password encoding
JWT generation
JWT validation
JWT authentication filter
Protected APIs
Role-based authorization

The login flow looks like:

For protected requests, the frontend automatically sends:

Authorization: Bearer

The backend then validates the JWT through the authentication filter and Spring Security context.

👥 3. Role-Based Authorization

I didn't want authentication to simply mean “the user is logged in.”

Different users should have different permissions.

ShopEase currently has USER and ADMIN roles.

For example:

USER
↓
Protected API
↓
Unauthorized operation
↓
403 Forbidden

while:

ADMIN
↓
Protected Admin API
↓
Allowed

This is used for operations such as product and specification management.

🛒 4. Building a Persistent Shopping Cart

The cart was where the frontend and backend really started behaving like one application.

The backend contains:

User
↓
Cart
↓
CartItem
↓
Product

The cart supports:

Add product
View cart
Update quantity
Remove item
Stock validation
Quantity validation
Subtotal
Total
Total item count

The APIs are:

POST /cart
GET /cart
PUT /cart/{itemId}
DELETE /cart/{itemId}

The important part was making the cart persistent.

If a user adds a product, logs out, and later logs in again, the cart is restored from the database instead of being lost.

🤍 5. Adding Wishlist Functionality

After the cart, I implemented a user-specific persistent wishlist.

The backend provides:

POST /wishlist/{productId}
GET /wishlist
DELETE /wishlist/{itemId}

The frontend includes:

Wishlist button
Wishlist count
Wishlist drawer
Product cards
Add/remove functionality
Wishlist state synchronization
Empty wishlist UI

I also added duplicate-product handling and ownership validation.

The wishlist module is currently fully integrated and tested.

🧾 6. DTOs, Validation and Exception Handling

As the project became bigger, I realized that directly exposing entities through APIs wasn't a good approach.

So I introduced DTOs such as:

ProductRequestDTO
ProductResponseDTO

UserRequestDTO
UserResponseDTO

LoginRequestDTO
LoginResponseDTO

AddToCartRequestDTO
UpdateCartItemDTO

CartItemResponseDTO
CartResponseDTO

The purpose was to separate the API layer from the entity layer and control exactly what data enters and leaves the application.

I also implemented Jakarta Validation with annotations such as:

@notblank
@NotNull
@positive
@min
@max

and created a centralized GlobalExceptionHandler for validation, authentication, product, stock and cart-related errors.

🧾 7. Checkout and Orders

The project has now moved beyond just shopping-cart functionality.

Checkout and order management are implemented and tested.

The current flow is:

USER
↓
Cart
↓
Checkout
↓
POST /orders
↓
Order Success
↓
Order Details
↓
My Orders
↓
Order History

The backend supports:

POST /orders
GET /orders
GET /orders/{id}

It also handles user-specific order history and order-status transitions.

🚧 What's Next?

The next major target is payment integration.

I'm currently planning the Razorpay integration around:

Payment order creation
Payment verification
Payment status handling
Order-payment integration
Successful payment handling
Failed payment handling
Payment security
Payment testing

The frontend will also have payment initiation and success/failure handling.

After that, the longer-term roadmap includes production hardening, automated testing, Docker, CI/CD, deployment, and eventually more advanced architecture such as microservices and event-driven communication.

🧠 What I'm Learning From ShopEase

The biggest thing I've learned from this project is that building a real application is very different from writing isolated code.

A feature isn't finished when the Java class compiles.

It has to go through a complete workflow:

Backend Development
↓
API Testing
↓
Frontend Development
↓
API Integration
↓
Full Feature Testing
↓
Bug Fixing
↓
Git Commit
↓
Git Push

That process has become an important part of how I'm developing ShopEase.

🚀 What's Next for ShopEase?

The final goal is to take ShopEase from a learning project toward a production-oriented full-stack e-commerce application.

The long-term architecture is planned around:

Frontend
↓
Spring Boot Backend
↓
MySQL
↓
JWT Authentication
↓
Role-Based Authorization
↓
Cart + Wishlist
↓
Checkout
↓
Orders
↓
Payment
↓
Admin Dashboard
↓
Inventory
↓
Testing
↓
Docker
↓
CI/CD
↓
Cloud Deployment

The project is being developed module by module, with backend development, frontend integration, testing and Git commits forming the development workflow

ShopEase is still a work in progress.

I'm not trying to rush toward calling it “production-ready.” There are still important areas left to build, including payment integration, automated testing, Docker, CI/CD, deployment and production hardening.

For me, that's actually the point of the project.

I'm using ShopEase to understand how a real full-stack application grows from individual features into a complete system — one module at a time.

GitHub: github.com/Shitanshu686
Portfolio: shitanshu686.github.io/ShitanshuJhaaaa/
LinkedIn: linkedin.com/in/shitanshu-jha-738012342/