Designing Payment Business Architecture: Process Decomposition, Sequence Diagram, and Structural Design

Business Background

In most business systems, payment‑related functions appear to varying degrees, and developers with limited experience often feel nervous when dealing with payment settlement logic because any detail error can cause reconciliation anomalies.

After an error occurs, fixing the process is time‑consuming and may involve data adjustment, potentially leading to chaotic accounts that require manual intervention.

Payment scenarios involve complex business rules, lengthy processes, third‑party integration, and numerous technical details such as transaction management, asynchronous handling, retry mechanisms, and locking.

Payment Business

1. Process Decomposition

When facing complex business, the basic ability is to split the workflow 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: clear handling of user funds, e.g., available balance, frozen amount, statements.

Transaction Flow: records of all fund movements, including recharge, withdrawal, refund, etc.

Payment Integration: interaction with third‑party payment platforms, requiring request and message logging.

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

Although real‑world details are more complex, the overall thinking remains similar; designers should create sequence diagrams for each module and plan node interactions.

2. Process Sequence

By designing a sequence diagram, we can analyze how each node should cooperate. Payment business is usually divided into three core phases: pre‑payment, payment integration, and post‑payment.

Pre‑payment: when an order is placed, build the order model, validate inventory and product status, freeze user funds, and generate a transaction record; the status is "awaiting payment".

Payment Integration: after the pre‑payment model is initialized, construct a request to the third‑party payment platform, initiate the payment flow, and record request parameters while waiting for the payment result notification.

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

Understanding and splitting the business clearly simplifies the complex scenario, after which appropriate data structures can be designed.

3. Structural Design

Based on the analysis and sequence diagram, a basic data‑structure design can be derived:

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

Transaction Record: stores user actions; a single order may generate multiple transaction details (e.g., shopping cart).

Transaction Detail: due to order splitting, funds may be divided into multiple details and sent to different merchants.

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

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, amount.

Even this simple design reveals the inherent complexity of payment business, which grows further when coupons, discounts, or other promotional rules are added.

With clear development standards, complex versions require developers to output business decomposition, sequence, and structural design for unified review before implementation, ensuring high quality.

Related Business

Beyond the core payment flow, many other domains are involved, such as product management, inventory management, logistics, and coupon rules.

Product Management

Product Entity: maintains product information, specifications, pricing tiers, and detailed descriptions.

Warehouse Management: after order splitting, verify warehouse information, freeze inventory, and handle post‑payment shipping.

Coupon Rules

Coupon Entity: supports various discount models (full‑reduction, percentage, tiered pricing, validity periods, etc.).

Distribution Rules: support daily operations, user lifecycle maintenance, and channel conversion for marketing activities.

These product and coupon services are tightly coupled with the payment process, affecting order splitting, inventory checks, discount application, and refund handling.

Practical Summary

Business Model: clear understanding, modular decomposition, and design of sequence and data structures.

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

Locking & Retry: after payment success, lock order identifiers to avoid data issues caused by message retries.

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

Process Maintenance: provide visual workflow tools and manual maintenance mechanisms to keep the process reliable.

Complex business scenarios require long‑term iterative improvement, but mastering core logic and gradually simplifying the implementation leads to robust solutions.