Design and Implementation of Payment Business Architecture

In most business systems, payment-related functions are inevitably involved. For newcomers, the most stressful part is handling the detailed logic of payment settlement, as any minor issue can cause reconciliation anomalies.

When errors occur, fixing the process incurs high time costs and may require data reconciliation, often leading to chaotic accounts that need manual intervention.

1. Business Background

Typically, business systems involve payment functions to varying degrees. The most nervous aspect for inexperienced developers is dealing with payment settlement logic, where any detail can trigger reconciliation errors.

2. Payment Business

1) Process Decomposition

When facing complex business, the basic ability is to split the process into modules, manage each module, and then connect them to form a coherent solution.

The typical transaction scenario can be divided into four modules:

Account Management: managing user funds such as available balance, frozen amount, and statements.

Transaction Ledger: recording all fund movements, including payments, recharges, withdrawals, and refunds.

Payment Integration: handling requests and messages to third‑party payment platforms.

Order Structure: managing order models, split strategies, and product specifications in e‑commerce.

Although the diagram simplifies the flow, real‑world details are far more complex; nevertheless, the design thinking remains similar.

2) Process Sequence

Designing a sequence diagram helps analyze how each node should cooperate. The payment process is usually divided into three core stages:

Pre‑payment: when an order is placed, the order model is built, inventory and product status are validated, funds are frozen, and a transaction record is created with a “pending” status.

Payment Integration: after the pre‑payment model succeeds, a request is sent to the third‑party payment platform, the request and parameters are logged, and the system waits for the payment result notification.

Post‑payment: based on the success or failure of the payment, the business model state is updated; successful payments trigger updates to transaction records, frozen funds, order structures, and inventory.

Understanding the business and splitting it clearly allows a well‑designed sequence to simplify a complex scenario, after which data structures can be designed.

3) Structural Design

Based on the analysis and sequence diagram, a basic data model can be designed as follows:

Account Management: core dimensions include total amount, available balance, and frozen amount.

Transaction Record: stores user transaction actions, which may generate multiple transaction details, e.g., shopping cart orders.

Transaction Detail: due to order splitting, funds may be distributed to different merchants.

Payment Integration: records request parameters and third‑party callback messages.

Order Record: a single order may contain multiple sub‑orders with various split strategies (warehouse, merchant, category, etc.).

Order Detail: manages information of each sub‑order, such as product, specifications, buyer/seller, unit price, quantity, and amount.

Even this simple design reveals the complexity of payment business, which further increases when coupons or discount rules are added.

3. Associated Business

The payment logic is closely linked with other e‑commerce components such as product management, inventory, logistics, and coupon rules.

Product Management

Maintains product information, specifications, pricing tiers, and builds product detail descriptions.

Warehouse Management: after order splitting, inventory is checked, frozen, and shipped post‑payment.

Coupon Rules

Coupon design must support various scenarios like full‑reduction, discount rates, tiered pricing, and validity periods.

Distribution rules support daily operations, user lifecycle maintenance, and channel conversion, providing a foundation for marketing activities.

4. Practice Summary

Business Model: clear understanding and decomposition of core nodes, designing corresponding sequence and data structures.

Transaction Management: commonly use TCC (Try‑Confirm‑Cancel) transaction pattern.

Locking and Retry: after payment success, lock order IDs to avoid data issues caused by retry mechanisms.

Fund Settlement: ensure precise amount calculations and reconciliation for each transaction.

Process Maintenance: provide visual process interfaces and manual maintenance mechanisms to reduce errors.

Complex business scenarios require long‑term iteration, but mastering core logic simplifies analysis, implementation, and innovation.