Designing a Generic Payment Core System: Key Components and Best Practices

1. Payment System Overview

Core system interaction diagram:

Business map diagram:

2. Core System Analysis

Transaction Core

The transaction core links business systems with underlying payment channels, allowing business logic to remain independent of payment details.

Diagram:

Basic transaction type abstraction diagram:

Multi‑table aggregation & order association diagram:

Payment Core

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

Overview diagram:

Payment behavior orchestration (plugin‑style development, configurable payment rules) diagram:

Exception handling (duplicate payments, partial payments, amount mismatches, other error scenarios) diagram:

Channel gateway diagram:

Fund accounting diagram:

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 throughout to prevent loss of context.

Data Consistency Governance

Large payment companies often use heavyweight distributed transactions for strict consistency, sacrificing development efficiency. Smaller businesses may adopt alternative strategies.

CAS Validation

Idempotency & Exception Compensation

Reconciliation

Near‑Real‑Time Reconciliation

DB Sharding

Asynchronization

Payment is the core of the transaction chain; to balance stability and efficiency, the system adopts asynchronous processing.

Message Asynchronization

External Payment Call Asynchronization

When obtaining pre‑payment credentials from third‑party providers, synchronous calls can cause long response times and block the payment flow. The solution is to split credential acquisition into a front‑gate service that performs the external call asynchronously.

Asynchronous Parallelization

Fund Accounting Asynchronization

Hot Account Separate Handling

Accounting Transaction Splitting

4. Production Practices

Performance Stress Testing

A stress‑test model simulates real‑world scenarios, writes test data to a shadow database to avoid impacting production, and evaluates both single‑machine and centralized link performance to identify stability limits and capacity ratios.

Stability Governance

Core Link Separation

Service Dependency Degradation

Source: cnblogs.com/88223100/p/How-to-design-a-payment-system.html