Backend Development 9 min read

Payment Business Process Analysis, Flow Decomposition, Sequence Design, and Structural Modeling

This article examines the complexities of payment systems by breaking down business processes into modular flows, illustrating sequence diagrams for pre‑payment, payment integration, and post‑payment stages, and proposing a structured data model that addresses transaction records, account management, order handling, and related e‑commerce features.

Architect's Guide
Architect's Guide
Architect's Guide
Payment Business Process Analysis, Flow Decomposition, Sequence Design, and Structural Modeling

In many business systems, payment‑related functions are inevitable, and developers often find the intricate settlement logic daunting because any detail can cause reconciliation errors, leading to costly manual interventions.

Payment scenarios involve numerous technical challenges such as transaction management, asynchronous processing, retry mechanisms, and locking, which require careful analysis of business logic and technical details.

1. Flow Decomposition

Complex business processes should be divided into modules, each managed independently, before integrating them into a complete workflow.

The typical transaction scenario can be split into four modules:

Account Management: clear handling of available balance, frozen amount, and statements.

Transaction Ledger: records of all fund movements, including recharge, withdrawal, and refund.

Payment Integration: logging requests and messages when interfacing with third‑party payment platforms.

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

2. Sequence Design

Designing a sequence diagram helps clarify how each node should cooperate. Payment processes are usually divided into three core phases: pre‑payment, payment integration, and post‑payment.

Pre‑payment: build the order model, validate inventory and product status, freeze funds, and generate a pending transaction record.

Payment Integration: after the pre‑payment model succeeds, construct a request to the third‑party payment gateway, record the request parameters, and await notification.

Post‑payment: based on the payment result, update business models; successful payments trigger updates to transaction records, frozen funds, order structures, and inventory.

3. Structural Design

From the analysis above, a basic data structure can be derived. The following diagram illustrates a reference design:

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

Transaction Record: stores user actions, potentially generating multiple transaction details (e.g., shopping cart orders).

Transaction Detail: splits a transaction into several records when an order is divided among multiple merchants.

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

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

Order Detail: manages information for each sub‑order, such as product, specifications, buyer/seller, unit price, quantity, and amount.

4. Related Business

Beyond the core payment flow, e‑commerce scenarios also involve product management, inventory control, logistics, and coupon rules.

Product Management

Product Entity: maintains product attributes, specifications, and pricing tiers.

Warehouse Management: after order splitting, verify stock, freeze inventory, and handle shipment.

Coupon Rules

Coupon Entity: supports various discount strategies such as full‑reduction, percentage, tiered pricing, and validity periods.

Distribution Rules: enable marketing activities, user lifecycle maintenance, and channel conversion.

5. Practical Summary

Business Model: clear understanding and modular decomposition of core nodes, with designed sequence and data structures.

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

Locking & Retry: lock order identifiers during post‑payment processing to avoid duplicate handling caused by retries.

Fund Settlement: ensure precise monetary calculations to pass reconciliation checks.

Process Maintenance: provide visual workflow tools and manual maintenance mechanisms to reduce errors.

Complex business scenarios require iterative refinement, but maintaining a solid grasp of core logic and systematic decomposition leads to higher quality implementations.

backendArchitecturetransactionpaymentbusiness process
Architect's Guide
Written by

Architect's Guide

Dedicated to sharing programmer-architect skills—Java backend, system, microservice, and distributed architectures—to help you become a senior architect.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.