Payment Business Process Design and Technical Considerations

1. Business Background

In most business systems, payment‑related functions appear to varying degrees. For developers with limited experience, handling payment settlement logic can be stressful because any detail error may cause reconciliation anomalies.

When errors occur, fixing the process is time‑consuming and often requires data balancing, which can lead to chaotic, untrackable accounts that need manual intervention.

Payment scenarios involve complex business rules, lengthy processes, and third‑party integrations, as well as technical details such as transaction management, asynchronous handling, retry mechanisms, and locking. The following sections analyze these specifics.

2. Payment Business

2.1 Process Decomposition

When facing complex business, the fundamental skill 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: For users with payment enabled, clear management of funds (available, frozen, bills, etc.) is required.

Transaction Flow: Records of all fund movements, including payments, top‑ups, withdrawals, refunds, 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 transactions.

Although the diagram shows a simplified flow, real‑world details are far more intricate; however, the overall thinking remains similar. Designing sequence diagrams for each module helps plan node interactions.

2.2 Process Sequence

Sequence diagrams clarify how nodes cooperate during three core stages: pre‑payment, payment integration, and post‑payment.

Pre‑payment: When an order is placed, an order model is built, inventory and product status are validated, funds are frozen, and a transaction record is created; the status remains “awaiting payment”.

Payment Integration: After the pre‑payment model succeeds, a request to the third‑party payment provider is constructed, the payment process is initiated, and request parameters are logged while awaiting notification.

Post‑payment: Based on the success or failure of the payment result, business models are updated; successful payments trigger updates to transaction records, frozen funds, order structures, and inventory.

Understanding and splitting the business logic, then designing the sequence flow, makes a complex scenario much clearer and prepares the data structures for implementation.

2.3 Structural Design

From the analysis and sequence diagrams, a basic dimensional structure can be derived. The following diagram serves as a reference.

Account Management: Core dimensions – account balance, available amount, frozen amount.

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

Transaction Detail: When an order is split, the payment may be divided into multiple details, directing funds to different merchants.

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

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

Order Detail: Manages information for each sub‑order: product, specifications, buyer/seller, unit price, quantity, amount, etc.

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

With clear development standards, complex versions require developers to output a decomposition of business logic, sequence diagrams, and structural designs, undergo unified reviews, and then proceed to implementation, ensuring high quality even for intricate scenarios.

3. Related Business

Beyond the core payment flow, e‑commerce transactions involve product management, inventory, logistics, and embedded discount rules.

Product Management

Product Core: Maintains product dimensions, provides specification options, pricing tiers, and detailed descriptions.

Warehouse Management: After order splitting, validates warehouse information, freezes inventory, and handles post‑payment shipping.

Coupon Rules

Coupon Core: Designs various discount rules (full‑reduction, percentage, tiered pricing, validity periods, etc.) to fit diverse scenarios.

Distribution Rules: Supports daily operations, user‑lifecycle maintenance, and channel conversion, providing a foundation for user‑group marketing.

These product and coupon functionalities are tightly coupled with the payment flow; for example, insufficient inventory after split may require product removal, and coupon usage influences payment calculations and refund handling.

4. Practical Summary

From a technical implementation perspective, key issues in payment processes include:

Business Model: Clear understanding of the domain, decomposition into core nodes, and design of sequence diagrams and data structures.

Transaction Management: Commonly using the TCC pattern – Try (pre‑process), Confirm, Cancel.

Locking and Retry: After payment success, messages trigger business updates; order‑level locking prevents duplicate processing from retry mechanisms.

Fund Settlement: Precise amount calculations are mandatory to avoid precision loss and ensure each transaction can be reconciled.

Process Maintenance: The workflow is hard to keep error‑free; developers should provide visual monitoring tools and manual adjustment capabilities.

Complex business scenarios require long‑term iterative improvement, but the foundation is a solid grasp of core logic; understanding evolves from complexity to simplicity, and implementation progresses from analysis to delivery and innovation.

Civilized discussion should focus on 交流技术 、 职位内推 、 行业探讨 .