Inside a Scalable Payment System: Architecture, Core Components, and Real‑World Practices

Payment is a core domain for any transaction‑based company, and this article outlines a typical payment system architecture that applies to most scenarios, consisting of a transaction core and a payment core.

1. Payment System Overview

Core System Interaction

Business Map

2. Core System Details

Transaction Core

The transaction core links business scenarios with the underlying payment layer, allowing business services to focus on their domain without dealing with payment details.

Payment Core

The payment core abstracts multiple payment types into four forms: 充值 、 提现 、 退款 、 转账. It also integrates various payment tools and orchestrates payment commands.

Payment Core Overview

Payment Behavior Orchestration

Its goal is to enable 插件式开发 and configurable payment rules for flexible development.

Exception Handling

Handles scenarios such as duplicate payments, partial payments, amount mismatches, and other anomalies.

Channel Gateway

Fund Accounting

3. Service Governance

Unified Platform Context

After defining system boundaries and business modeling, the platform is split into dozens of services. A unique business identifier is propagated across all services to prevent information loss.

Data Consistency Governance

Large payment companies often use heavyweight distributed transactions for strict consistency. For businesses that avoid distributed transactions, strategies such as CAS validation, idempotency, exception compensation, and various reconciliation approaches are employed.

CAS Validation

Idempotency & Exception Compensation

Reconciliation

Near‑Real‑Time Reconciliation

Database Sharding

Asynchrony

Because payment is the core link of the transaction chain, asynchronous processing is used to improve stability and execution efficiency.

Message Asynchrony

External Payment Call Asynchrony

External payment interactions often require fetching pre‑payment vouchers from third‑party services, which can cause long response times and block the payment chain. By front‑loading the voucher acquisition to an independent gateway service, the call becomes asynchronous.

Asynchronous Parallelism

Fund Accounting Asynchrony

Hot Account Separate Processing

Accounting Transaction Segmentation

4. Production Practices

Performance Stress Testing

Build stress‑test models that simulate real scenarios, route test data to shadow databases, and consider both single‑machine performance and centralized link capacity to identify stability and capacity bottlenecks.

Stability Governance

Core Link Separation

Service Dependency Degradation