Inside the Core of Payment Systems: Architecture, Governance, and Scaling Strategies

Payment is the core domain of any transaction‑oriented company, and the overall architecture can be viewed as a Transaction Core plus a Payment Core.

1. Payment System Overview

Core System Interaction

Business Map

2. Core System Analysis

Transaction Core

The Transaction Core links the company's business systems with the underlying payment layer, allowing business systems to focus on business 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 充值, 提现, 退款, 转账 and integrates various payment tools.

Payment Core Overview

Payment Behavior Orchestration

Its goal is to achieve 插件式开发, 支付规则可配置 flexible development.

Exception Handling

Handles duplicate payment, partial payment, amount mismatch, and other anomaly 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; a unified context identifier (unique business code) is passed throughout to ensure business information is not lost.

Data Consistency Governance

Large payment companies adopt strict data‑consistency solutions such as distributed transactions, sacrificing development efficiency for stability; alternatives for businesses that avoid distributed transactions are also discussed.

CAS Validation

Idempotency & Compensation

Reconciliation

Near Real‑time Reconciliation

DB Sharding

Asynchronization

Because payment is the core link of the transaction chain, asynchronization is used to balance stability and execution efficiency.

Message Asynchronization

External Payment Call Asynchronization

External payments often require obtaining a pre‑payment credential; synchronous calls lead to long response times, blocking the entire payment chain and potentially causing service denial under high QPS.

Therefore, credential acquisition can be split via a front‑gate service that obtains internal credentials and asynchronously calls third‑party providers.

Asynchronous Parallelism

Fund Accounting Asynchronization

Hot Account Accounting Separate Handling

Accounting Transaction Segmentation

4. Production Practices

Performance Stress Testing

Build stress models that simulate real scenarios; test data flows into a shadow database without affecting normal business; consider both single‑machine and centralized link performance; identify system stability and capacity bottlenecks.

Stability Governance

Core Link Separation

Service Dependency Degradation