Zero to Checkout: How I Engineered a Custom Payment Gateway

Most developers stick to integrating slick solutions like Stripe or Razorpay for payments. But what if you rolled up your sleeves and built your own payment gateway from scratch complete with banks, risk engines, settlements, refunds, and tokenization, just like the big fintech players?

That’s exactly what I did with PayProX. It’s a microservices-based, cloud-deployed payment gateway ecosystem built for scalability, modularity, and rock-solid security.

In this post, I’m stoked to share how I pulled it off, the lessons I learned along the way, and why this project is an awesome challenge for anyone curious about backend engineering or fintech systems.

Why I Chose to Build a Payment Gateway from Scratch

Every time you click “Pay Now,” a complex network of systems springs to life:

1. Your request flows to a Payment Gateway.
2. The Payment Processor connects with Card Networks (like Visa or MasterCard).
3. Your bank (the Issuer) approves or declines the transaction.
4. The merchant’s bank (the Acquirer) facilitates the fund settlement.
5. Fraud detection, tokenization, and refunds operate seamlessly behind the scenes.

I wasn’t content with just understanding this process. I wanted to create it. My mission was to dive deep into backend engineering and uncover what makes financial systems secure, scalable, and robust.

A Look at PayProX

Building a payment gateway from scratch was never about just writing code ,it was about understanding the invisible flow of money online. That’s how PayProX was born: a production-grade simulation of a real-world payment ecosystem, designed with scalability, security, and modularity in mind.

It’s a system that feels alive handling everything from a customer clicking “Pay Now,” to banks authorizing transactions, to merchants receiving their funds just like in the real world.

What Makes PayProX Special

Microservices Architecture → I split responsibilities across independent services for banks, merchants, customers, fraud checks, settlements, and tokenization. It keeps the system clean and realistic.

Cloud-Native Deployment → Frontend on Vercel, backend microservices on Render, and MongoDB Atlas powering all data, just like production setups.

Security by Design → Every sensitive action is protected: tokenization ensures card data is safe, internal authentication keeps services secure, and the risk engine catches suspicious activity.

Purpose & Scope

The goal of PayProX is to demonstrate how a secure and traceable payment system can be built from scratch. It enables developers and engineers to explore:

• End-to-end transaction processing
• Merchant and customer account management
• Risk evaluation and fraud prevention
• Tokenization and PCI-DSS aligned secure card handling
• Settlement and refund workflows

While this is a simulation, the system follows industry-standard practices and provides a production-grade feel, with independently deployable microservices and secure service-to-service communication.

PCI-DSS Alignment

PayProX is designed with security at its core. Sensitive card data is never stored in raw form; instead, a tokenization system is used to safeguard credentials. The project simulates PCI-DSS compliant practices, including:

• Credential isolation
• Secure authentication
• Fraud detection
• Traceable transaction logging

This makes PayProX not only a learning tool but also a demonstration of how real-world payment gateways maintain compliance and security while processing millions of transactions.

Architecture

The PayProX ecosystem follows a modular, service-oriented architecture where each microservice handles a distinct phase of the payment lifecycle. This design ensures scalability, traceability, and separation of concerns, while enabling secure communication between services.

Service-to-Service Communication

All microservices communicate via RESTful APIs secured with internal authentication headers. This ensures:

• Secure interactions: Only authorized services can access internal endpoints.
• Traceability: Every request can be logged and audited.
• Scalability: Each service can be deployed independently and horizontally scaled.

Data Flow

1. A customer initiates a payment on the merchant store.
2. The Merchant Service generates an order and requests a session from the Payment Gateway.
3. The Payment Gateway handles session creation, tokenization, and payment routing.
4. Transactions are screened by the Risk Engine for fraud detection.
5. Approved transactions are processed by the Acquirer Bank, which coordinates with the Issuer Bank for debit/credit.
6. Transaction metadata is persisted in MongoDB, and settlement is executed by the Settlement Engine.

Merchant & Customer Dashboards

To complement the backend microservices, PayProX includes dedicated dashboards for merchants and customers—built with React, deployed on Vercel, and secured via JWT authentication.
These dashboards simulate real-world fintech portals, enabling users to interact with the system in a secure and traceable way.

Merchant Dashboard

Purpose:
Gives merchants full control over their payment lifecycle—from order creation to settlement tracking.

Key Features:

• Order Management: Deploy the store
• Settlement Triggering: Manually initiate T+2 settlements
• Refund Approvals: Review and approve customer refund requests
• Transaction Logs: View ledger entries with timestamps and status

• Authentication: JWT-secured access with role-based routing

Customer Dashboard

Purpose:
Empowers customers to manage their payment methods, view transaction history, and request refunds.

Key Features:

• Stored Cards: View masked cards linked via Tokenization Service

• Transaction History: See past payments with IDs and status
• Refund Requests: Initiate refund flows with reason and timestamp
• Authentication: JWT-secured login with session expiry enforcement.

Backend Tie-In:

Connects to Customer Service, Issuer Bank, and Payment Gateway. All sensitive operations are validated via token and internal service headers

Meet the Services of PayProX

PayProX isn’t a monolith. it’s a constellation of microservices, each with a focused responsibility and hardened security. Here's how they work together:

Merchant Service

Role

Handles merchant onboarding, authentication, order creation, settlement triggers, and refund approvals.

Security Highlights

• JWT authentication for merchants
• verifyToken middleware ensures only authorized merchants can manage orders
• Settlement actions require secure internal API calls to Acquirer Bank

---

Customer Service

Role

Manages customer registration, authentication, stored payment methods, and refund requests.

Security Highlights

• Token-based authentication protects customer data
• Sensitive payment info is never stored directly, linked via the Tokenization Service
• Service-to-service validation restricts sensitive operations to trusted services

---

Payment Gateway Service

Role

Acts as the orchestration layer , manages sessions, initiates payments/refunds, and routes requests between banks.

Security Highlights

• JWT-secured customer flows (verifyCustomerToken)
• Internal communication via internalAuth headers
• Tokenization ensures no raw card data is stored or transmitted
• Sessions expire after 10 minutes to reduce attack surface

---

Acquirer Bank Service

Role

Manages merchant accounts, balances, and transaction debits/credits.

Security Highlights

• Only trusted internal services can initiate balance updates
• Middleware validates internal tokens for account access
• Ledger updates are fully traceable for audits

---

Issuer Bank Service

Role

Manages customer accounts, validates balances, and processes payments/refunds.

Security Highlights

• Netbanking login requires valid session tokens
• Debit/credit operations are idempotent and logged
• Exposes only internal APIs that means no public access

---

Risk Engine Service

Role

Detects fraud using velocity checks, blacklist rules, and amount thresholds.

Security Highlights

• Stateless analysis prevents session hijacking
• Dynamic updates to blacklist and velocity thresholds
• Suspicious requests blocked before reaching banks

---

Settlement Engine Service

Role

Handles T+2 settlement logic, merchant payouts, and reconciliation.

Security Highlights

• Only merchants can trigger settlements (manual today, automated soon)
• Internal authentication required for Acquirer credit operations
• Duplicate settlements prevented via transaction state management

Tokenization Service

Role

Replaces sensitive card data with unique, irreversible tokens.

Security Highlights

• PCI-DSS aligned—no raw card data stored
• Only last 4 digits + expiry stored for reference
• Token verification prevents replay attacks and ensures authenticity

Final Thoughts

PayProX isn’t just a side project, it’s a deep dive into the architecture, security, and complexity of real-world financial systems. From tokenization to fraud detection, every service is designed to reflect production-grade thinking.
Whether you're a backend engineer curious about fintech, a recruiter evaluating system design skills, or a developer looking to build secure, scalable microservices. PayProX is proof that you don’t need billion-dollar infrastructure to simulate billion-dollar flows.
I built this to learn, to challenge myself, and to show what’s possible when you combine curiosity with clean architecture.

Let’s Connect

If you’re hiring, collaborating, or just curious about how this works under the hood, I’d love to chat.
Check out the GitHub repo, explore the live demo, or reach out on LinkedIn.