Designing Complex Payment Systems: Architecture, Process Decomposition, and Best Practices

1. Business Background

In most business systems, payment‑related functions inevitably appear. For developers with limited experience, the most stressful part is handling the intricate settlement logic, where any detail error can cause reconciliation anomalies.

When errors occur, fixing the process is time‑consuming and often requires manual data adjustments, leading to chaotic accounting that demands human intervention.

2. Payment Business

1) Process Decomposition – Complex business should be broken into modules, each managed independently, then linked to form a complete solution.

The typical transaction scenario can be divided into four modules:

Account Management: clear handling of available, frozen, and billed amounts for users who have enabled payment.

Transaction Ledger: records of all fund movements, including payments, recharges, withdrawals, refunds, etc.

Payment Integration: logging of third‑party payment requests and messages.

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

Although real‑world details are far more complex, the overall thinking remains consistent: design sequence diagrams for each module and plan node interactions.

2) Flow Sequence – A sequence diagram helps analyze how nodes cooperate during three core stages: pre‑payment, payment integration, and post‑payment.

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

Payment Integration: after successful pre‑payment, construct third‑party request, initiate payment, and record request parameters while awaiting notification.

Post‑payment: based on success or failure, update business model status; successful payment triggers updates to transaction records, frozen funds, order structure, and inventory.

Understanding and splitting the business clearly, then designing the sequence, simplifies the complex scenario and guides data structure design.

3) Structural Design – Based on the analysis above, a basic dimensional design can be illustrated as follows:

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

Transaction Records: store user actions; a single transaction may generate multiple detail records (e.g., cart checkout).

Transaction Details: due to order splitting, funds may be distributed across several details to different merchants.

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

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

Order Details: manage each sub‑order’s product, specifications, buyer/seller, unit price, quantity, amount, etc.

Even this simple design reveals the inherent complexity of payment systems, which further increases when combined with coupons, discounts, and other promotional rules.

3. Related Business

Beyond the core payment flow, e‑commerce scenarios also involve product management, inventory management, logistics, and the embedding of promotional rules.

Product Management

Product Core: maintain product information, specifications, and pricing tiers.

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

Coupon Rules

Coupon Core: design various discount mechanisms such as full‑reduction, percentage discounts, tiered pricing, and validity periods.

Distribution Rules: support daily operations, user lifecycle management, and channel conversion, providing a foundation for marketing activities.

These product and coupon modules tightly interact with the payment flow—for example, insufficient stock after splitting may cancel the product, and coupon usage affects settlement and refunds.

4. Practice Summary

Business Model: clear understanding and modular decomposition, with designed sequence diagrams and data structures.

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

Locking & Retry: after payment success, lock the order ID to prevent duplicate processing caused by retry mechanisms.

Fund Settlement: ensure precise monetary calculations and verifiable reconciliation for every transaction.

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

Complex business scenarios require continuous iteration, but the key is to grasp core logic first, then move from analysis to implementation, and finally to innovation.