Designing a Robust Payment & Refund Model: Core Concepts and Pitfalls

Using a conceptual model to describe complex payment and refund flows clarifies the required entities, their relationships, and key design considerations.

Payment Scenarios

Typical payment methods include cash, online payment, and discount offers. Channels may be PC web, mini‑programs, or mobile apps, and platforms can be an integrated enterprise system, WeChat Pay, Alipay, etc.

Single payment – the user initiates payment for a single order.

Re‑payment – after a failure or timeout the user retries the same order.

Combined payment – the user selects multiple orders (potentially of different types) and pays them together.

Mixed payment – part of the amount is paid in cash, the remainder online.

- 支付：用户选择一个订单发起支付
- 再支付：用户订单支付失败或者超时支付后，再次发起支付
- 合并支付：用户可以选择多个订单（甚至可以是不同类型的订单）合并一起后发起支付
- 混合支付：一部分金额选择现金、一部分金额在线支付等

Refund Scenarios

Full refund – a one‑time complete refund.

Partial refund – the user specifies an amount less than the paid total; multiple partial refunds are allowed.

- 全额退款：一次性全额退款
- 部分退款：用户可输入小于支付金额的数值，这样可以发起多笔部分退款

Conceptual Model Design

One order may generate multiple payment details because different payment methods or split amounts are possible; therefore an order can have one or more payment detail records .

Payment details at the order level can be merged into a single payment order so that the downstream payment gateway processes them as one transaction.

The payment order is the entity that triggers the actual payment request to the external platform.

An order can involve several payment methods and amounts, leading to multiple refund requests. After a refund request is approved, a refund order is created.

The refund order drives the execution of the refund operation against the payment platform.

Because multiple channels may initiate payment concurrently, a distributed lock (e.g., Redis lock or database row lock) is required to prevent duplicate payments for the same order.

The payment platform should implement both asynchronous callbacks and a periodic polling timer to actively query the payment result, ensuring the user sees the real‑time status.

High concurrency across channels can cause state inconsistencies (e.g., payment succeeded but order still marked “pending”). Proper state machine design and flow control are essential to keep order status synchronized with payment outcomes.