Updated on 28 May, 202642 mins read 35 views

Modern payment systems are among the most complex distributed systems in the world. Every time a customer taps a card, scans a QR card, or clicks “Pay Now”, dozens of systems coordinate in milliseconds across banks, networks, fraud engines, ledgers, compliance systems, and merchant platforms.

Companies like Stripe, PayPal, Razorpay operate systems that process billions of dollars while maintaining:

  • High availability
  • Strong consistency
  • Low latency
  • Fraud resistance
  • Regulatory compliance
  • Global scalability

What is Payment System?

A payment system is an infrastrucuture that moves money between:

  • Customers
  • Merchants
  • Banks
  • Financial networks

It provides:

  • Payment processing
  • Transaction validation
  • Fraud checks
  • Ledger management
  • Settlement
  • Refunds
  • Reconciliation
  • Reporting

A payment system is not just “sending money.”

It is actually:

  • Distributed transaction orchestration
  • Financial event processing
  • Risk management
  • Compliance infrastructure
  • Real-time reliability engineering

Types of Payment Systems

Payment Gateway

A payment gateway securely collects payment information and forwards it for processing.

Examples:

  • Stripe
  • Razorpay
  • PayU

Responsibilities:

  • Tokenization
  • PCI compliance
  • Payment UI
  • API handling
  • Payment routing

Payment Processor

Handles communication between:

  • Banks
  • Card network
  • Issuers
  • Acquires

Responsibilities:

  • Authorization
  • Capture
  • Settlement coordination

Wallet Systems

Examples:

  • Paytm
  • PhonePe

Stores:

  • Internal balances
  • Credits
  • Cashback
  • Virtual money

Banking Rail Systems

Examples:

  • UPI
  • ACH
  • SWIFT
  • RTGS
  • NEFT
  • IMPS

These are national/global money transfer infrastructures.

Architectural Model

From a high-level desing perspective, there are essentially two major architectural models for implementing a payment system.

Model 1: PSP-Based Payment System

Your integrate with a:

Payment Service Provider (PSP)

such as:

  • Stripe
  • PayPal
  • Razorpay
  • Adyen

The PSP already has:

  • acquiring bank connections
  • card network integrations
  • PCI compliance
  • fraud systems
  • settlement systems
  • reconciliation infrastructure

You use their APIs:

Architecture

Customer
   ↓
Your Application
   ↓
PSP (Stripe/PayPal)
   ↓
Card Network (Visa/Mastercard)
   ↓
Issuing Bank

What You Build

You mainly build:

  • checkout flow
  • payment orchestration
  • business logic
  • merchant management
  • internal ledger
  • webhook handling

The PSP abstracts banking complexity.

Advantages

  1. Faster to build
    1. Very fast integration.
  2. Easier Compliance
    1. PSP handles most PCI requirements.
  3. Lower Operational Complexity
    1. No direct banking infrastructure.
  4. Multi-Payment Support
    1. Usually supports:
      1. cards
      2. wallets
      3. UPI
      4. BNPL
      5. netbanking
    2. through one API

Disadvantages:

  1. Higher Fees
    1. PSP takes processing fees.
  2. Less Control
    1. Limited routing optimization.
  3. Dependency on PSP
    1. If PSP has outage:

      Your payment flow is impacted

      Unless you implement multi-PSP routing.

Model 2: Direct Card Scheme / Direct Bank Integration

Instead of using a PSP, you connect directly to:

  • card schemes
  • acquiring banks
  • payment rails

Examples:

  • Visa
  • Mastercard
  • RuPay
  • banks directly

Architecture

Customer
   ↓
Your Payment Switch
   ↓
Visa/Mastercard/Bank
   ↓
Issuing Bank

Now you become:

  • payment processor
  • acquirer
  • switch operator
  • financial infrastructure provider

Advantages:

  1. Full Control
    1. You control:
      1. routing
      2. retries
      3. settlement
      4. authorization optimization
  2. Better Economics at Scale
    1. Large transaction volumes reduces dependency costs.
  3. Better Authorization Rates
    1. Smart routing improves success rates.
  4. Infrastructure Ownership
    1. You own the entire payment flow.

Disadvantages:

  1. Extremely Difficult
    1. You must build:
      1. finanical messaging systems
      2. distributed ledgers
      3. reconciliation engines
      4. settlement systems
  2. Heavy Compliance
    1. Requires:
      1. audits
      2. certifications
      3. HSMs
      4. PCI DSS Level 2
      5. bank partnerships
  3. 24/7 Critical Infrastructure
    1. Failures becomes:

      Financial incidents

      not just application bugs.

Payment Layer Stack

One of the most important things to understand in payment system design is:

Payments are layered systems

Most engineers initially think:

Frontend -> Stripe API -> Money transferred

But in reality, the payment ecosystem is a deep multi-layered financial network involving:

  • merchants
  • gateways
  • processors
  • acquirers
  • card schemes
  • issuer banks
  • settelement systems

The Complete Payment Layer Stack

┌──────────────────────────────┐
│ Customer / Card Holder       │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Merchant Application         │
│ (Amazon/Uber/Swiggy/etc.)    │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Payment Gateway / PSP        │
│ (Stripe/Razorpay/PayPal)     │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Payment Processor / Acquirer │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Card Network / Card Scheme   │
│ (Visa/Mastercard/RuPay)      │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Issuing Bank                 │
│ (Customer's Bank)            │
└──────────────────────────────┘

Layer 1 – Customer Layer

This is the payment initiator.

The customer is the entity trying to transfer money.

Examples:

  • card holder
  • UPI user
  • wallet owner
  • bank account holder

The customer owns:

  • debit card
  • credit card
  • bank account
  • wallet balance
  • UPI account
  • virtual payment address (VPA)

Responsibilties:

The customer:

  • initiates payment
  • authenticates payment
  • approves transaction

Authentication Methods:

Examples:

  • PIN
  • OTP
  • CVV
  • biometric authentication
  • 3DSecure
  • device authentication

Layer 2 – Merchant Layer / User Application Layer

This is the business application layer where the payment originates.

The merchant is the business receiving money.

Examples:

  • Ecommerce
    • Amazon
    • Flipkart
  • Ride Sharing
    • Uber
    • Rapido
  • Food Delivery
    • Swiggy
    • Zomato
  • UPI Apps / Wallets
    • PhonePe
    • Google Pay
    • Paytm

The merchant applications:

  • creates payment requests
  • displays checkout UI
  • handles order lifecycle

Merchant Responsibilities:

The merchant system usually manages:

  • cart service
  • order management
  • checkout flow
  • payment initiation
  • refund
  • subscriptions
  • invoices
  • payment history

Example:

User clicks:
Pay ₹1000

Merchant creates:

POST /payments

The merchant layer:

Does NOT move money directly

It only initiates payment workflows.

Layer 3 – Payment Gateway / PSP (Payment Service Provider) Layer

This is where most developers interact.

Examples:

  • Stripe
  • PayPal
  • Razorpay
  • Adyen

What is a Payment Gateway?

A payment gateway is:

The secure entry point into financial networks

It abstracts:

  • banking protocols
  • acquiring systems
  • card networks
  • settlement complexity

behind APIs.

PSP Responsibilities

A PSP typically handles:

  • tokenization (tokenize sensitive data)
  • PCI DSS compliance
  • fraud checks
  • payment orchestration
  • retries
  • acquiring integrations
  • webhook systems
  • SDKs/UI
  • currency conversion
  • payment session management

Why PSPs Exist

Without PSPs, every company would need direct integration with:

  • banks
  • Visa
  • Mastercard
  • settlement systems

which is extremely difficult.

PSP Architecture:

Merchant
    ↓
Stripe/Razorpay
    ↓
Financial Infrastructure

Layer 4 – Payment Orchestration & Processing Layer

This layer decides how the payment should be processed.

Responsibilties:

  • choose payment route
  • choose payment rail
  • smart retry logic
  • provider failover
  • optimize success rate
  • optimize processing cost
  • transaction routing
  • authorization orchestration

Example logic:

If UPI PSP A fails
    →
Retry using PSP B

If Card Acquirer A latency high
    →
Switch to Acquirer B

This layer is less visible to normal developers.

Why This Layer Exists:

Different:

  • banks
  • PSPs
  • acquirers
  • networks

have different:

  • uptime
  • latency
  • success rate
  • processing fees

The orchestrator optimizes:

Reliability + Cost + Conversion Rate

Processor Responsibilities

Processors:

  • authorize transactions
  • route payment messages
  • communicate with schemes
  • manage reversals
  • manage captures
  • handle settlement coordination

Acquirer (Acquiring Bank)

The acquirer is:

The merchant's bank

It accepts card payments on behalf of merchants.

Important Insight

Some companies combine:

  • PSP
  • orchestrator
  • processor
  • acquirer

into one stack, like Adyen, Stripe

Layer 5 – Card Network / Card Scheme / Payment Rails Network

This is:

The global money routing highway

Examples:

Card Networks

  • Visa
  • Mastercard
  • RuPay

Banking Rails

  • SWIFT (international)
  • NPCI (UPI)
  • NEFT
  • IMPS
  • ACH
  • RTGS

Responsibilities:

Payment rails:

  • route authorization requests
  • standardize payment messaging
  • coordinate settlement
  • define interchange rules
  • provide global interoperability

Important Clarification

Card schemeas usually:

Do NOT hold customer money

Banks hold money.

Schemes provide:

The network infrastructure

Example Flow:

Merchant
   ↓
Stripe
   ↓
Visa
   ↓
HDFC Bank

Visa routes the authorization request.

Layer 6 – Banking Layer

This is where:

Actual money exists

Types of banks:

  • Issuing bank (user's bank)
  • Acquiring bank (merchant's bank)

The issuer is:

The customer's bank

Examples:

  • HDFC Bank
  • ICICI Bank

Issuer Responsibilities

The issuer:

  • owns customer account
  • validates balances
  • validates card
  • perform risk checks
  • approves/rejects transaction

Authorization Logic

Issuer checks:

  • sufficient funds
  • CVV
  • expiry
  • risk score
  • OTP/3DS validation

Returns:

APPROVED / DECLINED

Layer 7 – Ledger & Accounting Layer

This is:

The financial source of truth

Purpose

Every payment becomes:

Accounting entries

Doubler-Entry Accounting:

Modern payment systems use:

Double-entry bookkeeping

Example transaction:

AccountDebitCredit
User Wallet-500 
Merchant Wallet +500

Responsibilties:

  • Ledger systems:
    • Maintain balances
    • Ensure consistency
    • Prevent double spending
    • Store immutable transaction history
    • Support auditing
    • Support reconciliation

If ledger is wrong, the entire system breaks.

Layer 8 – Settlement & Reconciliation Layer

This is:

The financial synchronization layer

Settlement

Settlement means:

Actual movement of money between instituitions

Authorization only reserves money.

Settlement transfers money.

Usually:

T+1 or T+2

Settlement Responsibilities

  • merchant payouts
  • interchange calculations
  • fee deductions
  • reserve handling
  • bank transfers
  • FX conversion

Reconciliation

Reconciliation ensures:

Internal records == External records

Reconciliation Sources

Compare:

  • internal ledger
  • PSP reports
  • bank statements
  • settlement files
  • network reports

Why Reconciliation Exists

Distributed systems fail.

Examples:

  • timeout after authorization
  • webhook lost
  • duplicate callback
  • delayed settlement

Reconciliation repairs inconsistencies.

Card vs UPI Ecosystem

Card Ecosystem

Customer
   ↓
Merchant App
   ↓
Stripe
   ↓
Visa/Mastercard
   ↓
Bank

UPI Ecosystem

Customer
   ↓
PhonePe/GPay
   ↓
NPCI UPI
   ↓
Bank

Requirements

Functional Requirements

These define:

What the system should do (features + behaviors)
  • Pay-in flow: payment system receives money from customer on behalf of sellers.
  • Pay-out flow: payment system sends money to sellers around the world.

Non-functional Requirements

  • Reliability and fault tolernace. Failed payments need to be carefully handled.
  • A reconciliation process between internal services (payment systems, accounting systems) and external services (payment service providers) is required. The process asynchronously verfies that the payment information across these systems is consistent.

Back of the envelope estimation

The system needs to process 1 million transactions per day, which is 1,000,000 transactions / 10^5 seconds = 10 transactions per second (TPS). 10 TPS is not a big number for a typical database.

Core Actors in Payment Systems

Customer

The payer.

Merchant

The business receiving money.

Issuing Bank

Customer's bank.

Acquiring Bank

Merchant's bank.

Card Network

Routes payment requests.

Examples:

  • Visa
  • Mastercard
  • RuPay

Payment Gateway

Handles orchestration.

Fraud Engine

Detects suspicious activity.

Settlement System

Moves actual money later.

Buy Me A Coffee

Leave a comment

Your email address will not be published. Required fields are marked *