Designing and Implementing Robust Payment Process Logic

1. Business Background

Payment‑related functions appear in most business systems, and developers with limited experience often feel nervous about the settlement logic because any detail can cause reconciliation anomalies.

When errors occur, fixing the flow is costly and may require manual data adjustments, leading to chaotic accounts that need human intervention.

The payment scenario involves complex business rules, settlement policies, long processes, and third‑party integration, as well as technical details such as transaction management, asynchronous handling, retry mechanisms, and locking.

2. Payment Business

1. Process Decomposition

When facing complex business, the fundamental ability is to split the workflow into modules, manage each module, and then connect them to form a clear problem‑solving approach.

The typical transaction scenario can be divided into four modules:

Account Management: clear handling of user funds such as available balance, frozen amount, and statements.

Transaction Ledger: records of all fund movements, covering payments, top‑ups, withdrawals, refunds, etc.

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

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

Although real‑world details are far more intricate, the overall thinking pattern remains similar; after decomposing the business, designers should create sequence diagrams for each module and plan node interactions.

2. Process Sequence

Sequence diagrams help analyse how each node should cooperate. Payment workflows are usually divided into three core stages: pre‑payment, payment integration, and post‑payment.

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 generated; the status is "awaiting payment".

Payment Integration: after the business model is initialized, a request to the third‑party payment platform is constructed, the payment process is triggered, and request parameters are recorded while awaiting the payment result notification.

Post‑payment: based on the success or failure of the payment, the business model status is updated. On success, transaction records, frozen funds, order structures, and inventory are all updated accordingly.

Understanding the business and splitting it clearly, then designing the sequence flow, makes a complex scenario much simpler before moving on to data‑structure design.

3. Structure Design

Based on the business analysis and sequence diagram, a basic dimensional structure can be produced. The following diagram serves as a reference.

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

Transaction Record: stores each user action; a single transaction may generate multiple detail records (e.g., shopping‑cart order).

Transaction Detail: because orders can be split, funds may be paid to different merchants, resulting in multiple detail lines.

Payment Integration: records request parameters and the callback payload from the third‑party platform.

Order Record: a single order may contain multiple sub‑orders; split strategies include warehouse, merchant, category, etc.

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

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 should require developers to output the decomposition logic, sequence diagram, and structural design, undergo unified review, and then proceed to implementation, ensuring high quality even for intricate business scenarios.

3. Related Business

The payment core logic is only part of the whole e‑commerce flow. Other related domains include product management, inventory, logistics, and coupon rules.

Product Management

Product Core: maintains multi‑dimensional product information, provides specification options, and defines basic pricing tiers.

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

Coupon Rules

Coupon Core: designs various discount mechanisms such as full‑reduction, percentage discount, tiered pricing, and validity periods to fit diverse scenarios.

Issuance Rules: support daily operations, user‑lifecycle maintenance, and channel conversion, providing the foundation for user‑group marketing.

These product and coupon modules are tightly linked to the payment flow—for example, insufficient inventory after order splitting may require product removal, and coupon usage strategies affect payment calculations and refund handling.

4. Practical Summary

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

Transaction Management: commonly uses the TCC (Try‑Confirm‑Cancel) pattern for distributed transactions.

Locking and Retry: after a payment succeeds, a success message triggers business updates; order‑level locking prevents duplicate processing caused by retry mechanisms.

Fund Settlement: precise amount calculations are required to avoid precision loss; each transaction must be verifiable through reconciliation.

Process Maintenance: the workflow itself is hard to keep error‑free; developers should provide visualized process interfaces and support manual maintenance mechanisms.

Complex business scenarios demand long‑term iteration, but the key is to grasp the core logic. Understanding the business moves from complexity to simplicity, while implementation progresses from shallow to deep: analysis → design → coding → innovation.