Payment Processing System Design (HLD & LLD)

Problem Statement

Design a payment processing system similar to Stripe, Razorpay, or PayPal that:

Accepts payments from users
Supports multiple payment methods
Communicates with external payment gateways
Ensures idempotency
Handles failures and retries
Maintains transaction history
Supports refunds
Provides high reliability and consistency

Functional Requirements

User initiates a payment.
Support multiple payment methods:
- Credit Card
- Debit Card
- UPI
- Wallet
- Net Banking
Process payments through external payment gateways.
Persist transaction details.
Handle payment success, failure, and pending states.
Support refunds.
Provide APIs for transaction status.

Non-Functional Requirements

High availability
Strong consistency for financial transactions
Idempotent APIs
PCI-compliant security
Horizontal scalability
Low latency

High-Level Design (HLD)

Architecture

flowchart TD
    C[Client]
    A[API Gateway]
    P[Payment Service]
    PR[Payment Processor]
    F[Fraud Detection]
    G[Gateway Adapter]
    X[External Payment Gateway]
    B[Bank / Card Network]

    C --> A --> P
    P --> PR
    P --> F
    PR --> G --> X --> B

Additional supporting components:

Transaction Database
Redis Cache
Kafka / Message Queue
Notification Service
Ledger Service

Payment Flow

sequenceDiagram
    participant User
    participant API as API Gateway
    participant PS as Payment Service
    participant PP as Payment Processor
    participant PG as Payment Gateway
    participant Bank

    User->>API: Create Payment
    API->>PS: Validate & Create Order
    PS->>PP: Process Payment
    PP->>PG: Gateway Request
    PG->>Bank: Authorize
    Bank-->>PG: Result
    PG-->>PS: Callback/Webhook
    PS-->>User: Payment Status

Microservices

Payment Service

Responsibilities:

Create payment
Validate request
Query payment status

APIs:

POST /payments
GET /payments/{id}
POST /payments/{id}/refund

Payment Processor

Responsible for:

Selecting payment gateway
Retrying failed requests
Idempotency handling

Gateway Adapter

Implements the Strategy Pattern.

Examples:

StripeAdapter
RazorpayAdapter
PaypalAdapter

Ledger Service

Maintains double-entry bookkeeping.

Account	Entry
User	Debit
Merchant	Credit

Notification Service

Sends:

Payment success
Payment failure
Refund confirmation

Channels:

Email
SMS
Push Notification

Database Design

Payments

payments
---------
id (UUID)
user_id
amount
currency
status
payment_method
gateway
created_at
updated_at

Transactions

transactions
-------------
id
payment_id
gateway_transaction_id
status
response_code
created_at

Refunds

refunds
--------
id
payment_id
amount
status
created_at

Idempotency

To prevent duplicate payments when users retry requests:

Use an Idempotency-Key header.

Idempotency-Key: UUID

Store:

idempotency_key
request_hash
response

Duplicate requests return the previously stored response.

Failure Handling

Possible failures:

Gateway timeout
Network issues
Bank decline
Internal service failure

Solutions:

Retry with exponential backoff.
Use Kafka/RabbitMQ for asynchronous processing.
Apply Circuit Breaker (e.g., Resilience4j).

Payment Lifecycle

stateDiagram-v2
    [*] --> CREATED
    CREATED --> PROCESSING
    PROCESSING --> SUCCESS
    PROCESSING --> FAILED
    SUCCESS --> REFUNDED

States:

CREATED
PROCESSING
SUCCESS
FAILED
PENDING
REFUNDED

Security

PCI-DSS compliance
Tokenization of card data
Encryption
HTTPS
HMAC signature verification for webhooks

Webhook verification flow:

Gateway -> Webhook -> Verify Signature

Scaling Strategy

Horizontal Scaling

Payment Service -> Multiple Instances

Behind a load balancer.

Database Scaling

Read replicas
Sharding by merchant_id

Event-Driven Processing

Events:

PAYMENT_CREATED
PAYMENT_COMPLETED
PAYMENT_FAILED
REFUND_INITIATED

Low-Level Design (LLD)

Payment Entity

class Payment {

    private String id;
    private String userId;
    private double amount;
    private PaymentStatus status;
    private PaymentMethod method;
    private String gateway;
}

PaymentStatus

public enum PaymentStatus {
    CREATED,
    PROCESSING,
    SUCCESS,
    FAILED,
    REFUNDED
}

PaymentMethod

public enum PaymentMethod {
    CARD,
    UPI,
    NETBANKING,
    WALLET
}

PaymentGateway Interface

public interface PaymentGateway {

    PaymentResponse processPayment(PaymentRequest request);

}

StripeGateway

public class StripeGateway implements PaymentGateway {

    public PaymentResponse processPayment(PaymentRequest request) {
        // call stripe API
        return response;
    }

}

RazorpayGateway

public class RazorpayGateway implements PaymentGateway {

    public PaymentResponse processPayment(PaymentRequest request) {
        // call razorpay API
        return response;
    }

}

PaymentGatewayFactory

public class PaymentGatewayFactory {

    public static PaymentGateway getGateway(String gateway) {

        switch(gateway) {
            case "STRIPE":
                return new StripeGateway();
            case "RAZORPAY":
                return new RazorpayGateway();
            default:
                throw new IllegalArgumentException();
        }
    }

}

PaymentService

@Service
public class PaymentService {

    public PaymentResponse processPayment(PaymentRequest request) {

        PaymentGateway gateway =
            PaymentGatewayFactory.getGateway(request.getGateway());

        return gateway.processPayment(request);
    }

}

Design Patterns

Pattern	Usage
Strategy	Gateway adapters
Factory	Gateway selection
State	Payment lifecycle
Observer	Notifications
Circuit Breaker	Gateway resilience

Advanced Topics

Distributed locking (Redis) to prevent duplicate processing.
Outbox Pattern for reliable DB + event publishing.
Saga Pattern for refund orchestration.
Rate limiting for fraud prevention.

Common Interview Follow-up Questions

How do you ensure exactly-once payment processing?
How do you design a financial ledger?
How do you reconcile payment mismatches?
How do you recover from partial failures?

Key Takeaways

Separate orchestration, gateway integration, ledger, and notification concerns.
Idempotency is critical to avoid duplicate charges.
Event-driven architecture improves scalability and resilience.
Strategy and Factory patterns simplify multi-gateway support.
Strong consistency, security, and auditability are essential for payment systems.