How Do You Design a Global Payment Processing System Like PayPal?

TL;DR

Design a global payment processing system like PayPal with three layers: clients, specialized microservices, and fit-for-purpose data stores. The platform should support one-time and recurring payments, refunds, disputes, multiple currencies, thousands of transactions per second, and 99.99% uptime. Relational databases protect critical financial records, while asynchronous messaging, partitioning, caching, idempotency, retries, circuit breakers, and sagas improve scale and resilience. Read on to see how these components work together.

Transcript

hey everyone today we explore the design of a global payment system much like PayPal that handles high transaction volumes and sells both merchants and consumers worldwide I'll walk through each step of the design discuss how various components interact and analyze the trade-offs involved in making key architectural decisions this is especially rel... Read More

Key Insights

• A payment gateway is the secure bridge between a client and the payment processor, encrypting payment details, requesting authorization, performing initial fraud checks, and routing transactions toward banks or card networks such as Visa or Mastercard.
• A payment processor is the engine that communicates with issuing banks, acquiring banks, and card networks to authorize transactions, capture funds, and settle payments. In the proposed design, payment, account, and transaction services collectively perform these responsibilities.
• The system architecture is divided into client, service, and data layers. Clients initiate requests, microservices execute business logic and contact external financial systems, and databases or caches preserve transactional records, sessions, logs, and frequently accessed information.
• The service layer is composed of specialized microservices for user profiles, payments, multi-currency accounts, transaction records, fraud monitoring, and notifications. Kafka or RabbitMQ supports asynchronous communication, reliable delivery, service decoupling, scalability, and fault tolerance.
• The database-per-service pattern gives each microservice ownership of its data and schema. Services exchange information through event-driven mechanisms instead of sharing databases, which promotes loose coupling and allows their storage models to remain independent.
• Relational databases such as PostgreSQL are used for critical financial data requiring ACID compliance. NoSQL databases such as Cassandra or MongoDB are used for high-throughput session data and event logs, while Redis caches frequently accessed information for faster responses.
• Payment metadata records who initiated a request, the merchant, payment method, currency, and current status. When conversion is required, the payment service uses the exchange rate stored for that request, then marks the final payment status after processing.
• Scalability and resilience depend on horizontal partitioning by user or region, read replicas, indexes on frequently queried fields, load balancing, caching, and robust processing patterns. The design also identifies circuit breakers, retries, idempotency, and sagas as important microservice patterns.

Questions & Answers

Q: How do you design a global payment processing system like PayPal?

Divide the architecture into client, service, and data layers. Clients submit requests through an API gateway, specialized microservices handle users, accounts, payments, transactions, fraud, and notifications, and relational databases, NoSQL stores, and caches hold different data types. Connect services asynchronously through a message broker such as Kafka or RabbitMQ to improve scalability, fault tolerance, and service independence.

Q: What requirements should a global payment platform support?

The platform should serve merchants and consumers worldwide and support one-time payments, recurring payments, refunds, disputes, multiple currencies, and real-time exchange rates. It should handle thousands of transactions per second while targeting 99.99% uptime, low latency, reliability, scalability, and strong security. It must also meet international and regional requirements such as PCI DSS and KYC.

Q: What is the difference between a payment gateway and a payment processor?

A payment gateway securely transfers payment data from a web app, mobile app, or other client toward the processor, handling encryption, authorization, initial fraud checks, and routing. The payment processor communicates with card networks such as Visa or Mastercard and with issuing and acquiring banks. It validates funds, authorizes transactions, captures money, and supports settlement into the merchant’s account.

Q: Which microservices are needed for global payment processing?

The design includes user, payment, account, transaction, fraud detection, and notification services. These services respectively manage authentication and KYC status, payment requests, multi-currency balances, durable financial records, fraud monitoring, and email, SMS, or push notifications. An API gateway provides authentication, routing, and rate limiting at the system entry point.

Q: Why should payment microservices use separate databases?

A database-per-service pattern gives each microservice ownership of its data and schema. Services exchange information through event-driven mechanisms rather than depending on a shared database, promoting loose coupling and data independence. Each service can therefore choose storage suited to its responsibilities.

Q: When should relational and NoSQL databases be used in a payment system?

Relational databases such as PostgreSQL should hold account balances, transactions, and other critical financial records requiring ACID compliance, durability, integrity, and traceability. NoSQL databases such as Cassandra or MongoDB can store high-throughput session data and event logs. Redis can cache frequently accessed information for faster responses.

Q: How does a payment service track multi-currency transactions?

The payment service records metadata including the initiator, merchant, payment method, currency, and current status. When conversion is required, it applies the exchange rate stored for that payment request. The status can remain pending during retries and then change to successful or failed after processing, while detailed records are stored by the transaction service.

Q: How can a global payment system improve scalability and resilience?

Partition databases horizontally by user or region, add read replicas, index frequently queried fields, cache commonly accessed data, and distribute traffic through load balancing. Use asynchronous messaging to decouple services and support reliable delivery. Idempotency, retries, circuit breakers, and sagas help the system handle duplicate requests, transient failures, unavailable dependencies, and multi-service transactions.

Summary & Key Takeaways

• A global payment platform must serve consumers, merchants, mobile applications, web portals, and third-party API clients. Its requirements include one-time and recurring payments, refunds, disputes, multiple currencies, real-time exchange rates, thousands of transactions per second, 99.99% availability, low latency, strong security, and compliance with PCI DSS and KYC requirements.

• The proposed architecture has client, service, and data layers. The service layer uses specialized microservices for users, payments, accounts, transactions, fraud detection, and notifications. An API gateway handles authentication, routing, and rate limiting, while Kafka or RabbitMQ enables reliable asynchronous communication and reduces direct dependencies among individual services.

• Critical transactional records belong in relational databases such as PostgreSQL because account balances and financial records require ACID compliance, durability, and traceability. NoSQL systems such as Cassandra or MongoDB can store sessions and event logs. Database-per-service ownership, horizontal partitioning, read replicas, indexes, caching, and resilient processing patterns improve independence, throughput, and reliability.