Designing a Robust Refund Center: Architecture, Processes, and Product Strategies

Collecting money is a skill, returning it is an art. Refunds are a common scenario in e‑commerce, home‑service, and food‑delivery businesses, but reverse transactions are not limited to refunds alone.

1. Reverse Business Overview

When users no longer need a product or service, or when defects exist, a reverse transaction is triggered. Refund orders may involve returning goods, coupons, or funds, with the fund return being the payment‑side reverse operation.

Designing an effective refund center requires a global view of refund business, considering factors such as coupon usage, promotional activities, multiple merchants, order status (canceled before payment, after shipment, after receipt), and full‑order versus partial refunds.

Orders that have been received are the most complex to reverse because settlement with merchants has already occurred, requiring reverse settlement and extending the processing chain.

Virtual goods are generally simpler to reverse than physical goods, while bundled orders are more complex than single‑item orders.

2. Refund Center

Refunds are the reverse operation of original payments and are often treated as a sub‑module of the payment system. As refund demand grows, many companies separate the refund function into an independent "refund center".

The independent refund center can support multiple refund methods (original‑route refund, payment‑to‑account, offline cash, balance refund, etc.) and offers various request channels (API, MQ, file upload, manual operation) as well as single and batch refund modes.

2.1 Product Architecture

The refund center is built around different refund products. For example, original‑route refund uses the original payment channel, while "refund‑to‑payment" (退转付) creates a new payment to the user when the original route is unavailable.

The refund center consists of four layers: the refund access layer (API, MQ, file, manual), the refund processing engine, the refund product layer, and the refund channel handling layer.

2.2 Refund Productization

Refund products are defined by dimensions such as product type, initiation method, refund type (full, partial, per‑item), original‑route refund timeliness, and fee handling. Combining these dimensions yields a rich set of refund capabilities.

2.3 Main Refund Process

The main flow starts with a refund request submission and ends with the refund center sending the request to the payment channel and receiving a response. It includes request parsing, validation, refund order creation, selection of refund method, and handling of merchant settlement deductions.

2.4 Refund Document Design

Refund documents have a three‑layer structure: a base refund order, a layer for method‑specific information, and a channel request record layer. They record order numbers, selected refund product, channel info, amounts, timestamps, etc.

2.5 Channel Attributes and Configuration

Payment channels configure attributes such as "supports refund", "refund timeliness", "fee refundability", and "fee rate", which are used during refund processing.

2.6 Full‑Channel Refund Capability Analysis

Different platforms integrate various payment channels, leading to diverse refund policies. E‑commerce platforms focus on WeChat Pay, Alipay, and quick payments, while payment institutions deal with UnionPay or the national clearing system.

3. Refund‑to‑Payment (退转付)

When the original refund timeliness expires, the refund request can be transformed into a payment to the user. This requires collecting the user's receiving account information, either manually or via a prompt in the order center.

The system creates a new payment order labeled "refund‑to‑payment" linked to the original refund order, ensuring that the total refunded amount never exceeds the original payment.

The payment and refund states are synchronized so that a successful refund‑to‑payment updates the original refund order status accordingly.

Overall, the refund‑to‑payment feature is considered a specialized refund product rather than a separate payment function.