Design and Implementation of an Extensible Transaction Settlement Testing System

The transaction settlement system consists of clearing and settlement components; clearing processes upstream split‑payment requests into standard records, while settlement handles fund transfers based on those records.

Testing the settlement system verifies that all parties' payments, refunds, and adjustments are correct, balances are maintained, and payment methods and timings are accurate.

Current Situation

Currently, the clearing system receives split‑payment requests from multiple business lines, generates settlement records according to user configurations and calculation rules, and invokes the payment center for fund transfers and account bookkeeping. The settlement system operates as an independent service between the order system and the payment system.

As business expands, the clearing system must handle increasingly diverse order attributes and promotional activities, introducing custom split‑payment requests and more varied settlement targets. Existing test code is tightly coupled with the order test system, making it unsuitable for new split‑payment scenarios, and the lack of structured storage for split‑payment attributes hampers extensibility.

Design Requirements for the Settlement Testing System

The testing system should be an independent module, separable from order testing, and support testing of various business orders, including split‑payment, regular refunds, and after‑sale refunds.

Split‑payment timing should be configurable based on user attributes.

Red packets, promotions, and service types should be addable flexibly.

Strategies such as user freight charges should be configurable.

Components of the Settlement Testing System

According to the analysis, the system comprises three parts:

Business Order Attributes

This input module defines clear entity parameters; testers set appropriate parameters based on order flow status.

Calculation Engine

Based on split‑payment types, rules, attribute priorities, and strategy formulas, the engine aggregates or deducts amounts to compute the payable amounts for various targets such as seller net receipt, buyer refund, and platform subsidy, generating corresponding settlement records for verification.

Record Verification

Settlement records are classified by fund flow direction (receive, supplement, pay, refund, return supplement). Verification ensures overall account balance, checks amounts, settlement methods, and timestamps, and confirms that the flow of target account amounts aligns with the settlement records.

Design Implementation

The current platform order settlement testing system is built on a dynamic proxy design. A settlement verification switch is added to the order test system’s verification proxy; based on order status and custom early split‑payment timing, the system decides whether to perform split‑payment. When required, relevant split‑payment attributes from the order context are passed to the settlement testing module for validation.

Conclusion

The article shares a testing approach for settlement business within a transaction system, illustrating a method to solve a class of problems rather than a specific business case. By abstracting test cases into chain‑style designs and dynamic proxies, the solution maintains clear transaction flows while accommodating evolving business requirements such as promotions, red packets, and complex split‑payment scenarios.