Overview and Architecture of a Payment System

1. Payment System Overview

Payment is the lifeblood of transaction‑oriented companies; the overall architecture can be seen as two major subsystems: the transaction core, which connects business scenarios to underlying payment mechanisms, and the payment core, which executes a series of operations such as recharge, withdrawal, refund, and transfer.

2. Core System Details

Transaction Core

The transaction core abstracts basic transaction types, aggregates data across multiple tables, and links orders, allowing business services to focus on domain logic without dealing with low‑level payment details.

Basic Transaction Type Abstraction

Defines a unified model for various transaction flows.

Multi‑Table Aggregation & Order Association

Combines related tables to maintain consistency of order information.

Payment Core

The payment core abstracts multiple payment modalities into four unified forms: Recharge , Withdrawal , Refund , and Transfer . It also integrates various payment tools and supports plugin‑style development with configurable payment rules.

Payment Core Overview

Provides a modular framework for handling different payment scenarios.

Payment Behavior Orchestration

Enables plugin‑based development and configurable payment rules for flexible implementation.

Exception Handling

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

Channel Gateway

Acts as the entry point that routes payment requests to appropriate downstream services and external payment providers.

Fund Management

Manages the flow of funds, including settlement and reconciliation processes.

3. Service Governance

Unified Platform Context

By defining a unique business identifier that travels across all services, the platform ensures that business information is not lost during inter‑service communication.

Data Consistency Governance

Large payment companies often employ strict distributed transaction mechanisms to guarantee data stability; alternatives such as CAS validation, idempotency, and compensation are discussed for services that cannot use heavyweight transactions.

CAS Validation

Ensures atomic updates of critical data.

Idempotency & Exception Compensation

Provides mechanisms to safely retry operations without side effects.

Reconciliation

Describes both batch and near‑real‑time reconciliation approaches.

Database Sharding

Splits data across multiple databases to improve scalability and performance.

Asynchronization

To balance stability and throughput, key payment flows are made asynchronous.

Message Asynchronization

Uses message queues to decouple processing steps.

External Payment Call Asynchronization

Wraps third‑party payment interactions in a front‑gate service that obtains internal credentials and then calls the external provider asynchronously.

Asynchronous Parallelism

Executes independent tasks in parallel to reduce overall latency.

Fund Accounting Asynchronization

Handles accounting operations in an asynchronous manner to avoid blocking critical paths.

Hot Account Separate Processing

Isolates high‑frequency accounts for specialized handling.

Accounting Transaction Segmentation

Breaks down large accounting transactions into smaller, manageable units.

4. Production Practices

Performance Stress Testing

Builds realistic load models, directs test data to shadow databases, and evaluates both single‑machine and clustered performance to identify stability limits and capacity ratios.

Stability Governance

Implements strategies such as core‑link separation and service dependency degradation to maintain system reliability under high load.

Core Link Separation

Divides critical processing paths into independent services to reduce contention.

Service Dependency Degradation

Provides fallback mechanisms when downstream services become unavailable.