Overview and Architecture of a Payment System

Payments are the core domain of any company with transactional business, and the payment system is essential for its lifeline. Ignoring the specific architectures of licensed financial institutions, the following components and flow represent the majority of payment scenarios. The overall structure can be viewed as two major systems: the transaction core and the payment core. The transaction system links business scenarios with underlying payment mechanisms, while the payment system handles calls to payment tools, reconciliation, settlement, and related operations.

1. Payment System Overview

Core System Interaction

Business Map

2. Core System Analysis

Transaction Core

The transaction core connects the company's business system with the underlying payment layer, allowing the business system to focus on its own logic without dealing with payment details.

Transaction Core

Basic Transaction Type Abstraction

Multi‑Table Aggregation & Order Association

Payment Core

The payment core abstracts multiple payment types into four fundamental operations: Recharge, Withdrawal, Refund, and Transfer. It also integrates various payment tools and orchestrates payment commands.

Payment Core Overview

Payment Behavior Orchestration

The goal is to achieve a plug‑in development model and configurable payment rules, enabling flexible development.

Exception Handling

Exception handling covers duplicate payments, partial payments, amount mismatches, and other abnormal scenarios.

Channel Gateway

Fund Accounting

3. Service Governance

Platform Unified Context

After defining system boundaries and splitting business models, the payment platform is divided into dozens of services. To ensure business information is not lost during inter‑service flow, a unique business identifier (unified context) is passed throughout the entire payment chain.

Data Consistency Governance

Large payment companies often adopt heavyweight distributed transaction solutions to guarantee data stability, sacrificing development efficiency. For businesses that cannot use distributed transactions, alternative strategies such as CAS validation, idempotency, and exception compensation are employed.

CAS Validation

Idempotency & Exception Compensation

Reconciliation

Near‑Real‑Time Reconciliation

Database Sharding

Asynchronization

Because payment is the core link of the transaction chain, stability and execution efficiency are achieved through asynchronous processing.

Message Asynchronization

External Payment Call Asynchronization

When interacting with third‑party payment providers, synchronous calls can cause long response times and block the entire payment flow, especially under high QPS. By front‑ending the credential acquisition with an independent gateway service, the request becomes asynchronous, improving throughput.

Asynchronous Parallelization

Fund Accounting Asynchronization

Hot Account Accounting Isolation

Accounting Transaction Segmentation

4. Production Practices

Performance Stress Testing

Build stress‑test models that simulate real‑world scenarios; route test data to shadow databases to avoid affecting normal business; pay attention to both single‑machine performance and centralized link capacity; identify system stability and capacity ratios.

Stability Governance

Core Link Separation

Service Dependency Degradation

For further reading and community discussion, join the architect exchange group via the QR code provided at the end of the original article.