How to Design a Global Payment Processing System

TL;DR

Design a global payment platform as layered, distributed microservices with separate services and databases for users, accounts, payments, transactions, fraud detection, and notifications. Use asynchronous messaging, relational storage for critical financial records, NoSQL storage for sessions and logs, and techniques such as partitioning, read replicas, indexing, caching, load balancing, idempotency, retries, circuit breakers, and sagas to support reliability and scale.

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: What is the difference between a payment gateway and a payment processor?

A payment gateway securely transfers payment information from a web application, mobile application, or other client to the processing systems. It encrypts details, routes requests, supports authorization, and can perform initial fraud checks. A payment processor communicates with card networks and issuing or acquiring banks, validates funds, authorizes transactions, captures money, and supports settlement into the merchant’s account.

Q: How should a global payment processing system be structured?

A global payment system can be divided into three layers. The client layer includes web portals, mobile applications, and merchant API integrations. The service layer contains microservices that implement authentication, account management, payment processing, transaction recording, fraud detection, and notifications. The data layer combines relational databases, NoSQL stores, and caches according to the consistency and performance requirements of each data type.

Q: What requirements should a global payment platform support?

The platform should serve merchants and consumers worldwide while supporting one-time payments, recurring payments, refunds, dispute resolution, multiple currencies, and real-time exchange rates. It should process thousands of transactions per second and target 99.99% uptime. Its nonfunctional requirements include reliability, scalability, low latency, strong security, and compliance with international and regional obligations such as PCI DSS and KYC.

Q: Which microservices are needed for global payment processing?

The design uses a user service for authentication, profiles, and KYC status; a payment service for payment requests and external communication; an account service for multi-currency balances; and a transaction service for durable financial records. It also includes a fraud detection service for real-time monitoring and historical fraud information, plus a notification service for email, SMS, and push-message tracking.

Q: Why should payment microservices use separate databases?

A database-per-service model allows each microservice to own its information and database schema. This arrangement supports loose coupling and data independence because services do not directly depend on a shared schema. Instead, they communicate through event-driven mechanisms such as Kafka. User, account, payment, transaction, fraud, and notification services can therefore maintain storage designed around their respective responsibilities.

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

Relational databases such as PostgreSQL should store critical transactional information, account balances, and other financial records that require ACID compliance, integrity, durability, and traceability. NoSQL databases such as Cassandra or MongoDB are suitable for noncritical, high-throughput information such as login sessions, tokens, timestamps, expiration details, and event logs. Redis can cache frequently accessed data to accelerate responses.

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

Before processing begins, the payment service records metadata including the initiator, merchant, payment method, currency, and current payment status. If conversion is necessary, it looks up the relevant exchange rate in the currency exchange-rate table and applies that rate. During retries, the request can remain pending. After completion, the request becomes successful or failed, while detailed records go to the transaction database.

Q: How can a global payment platform improve scalability and reliability?

The platform can partition databases horizontally by user identifiers or regions, add read replicas for read performance and redundancy, and index frequently queried fields. Load balancing and caching further improve performance. Kafka or RabbitMQ decouples services through asynchronous communication. The design also highlights circuit breakers, retries, idempotency, and saga handling as resilient microservice patterns for payment processing.

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.