Refund and Settlement Operations Handbook: Windows, Partial Refunds, Settlement Cycles, and Withdrawals
Once payments go live, refunds and settlement become daily operations. The technical difficulty is low, but the rule details are numerous, real money is involved, and mistakes become customer complaints. This handbook is organized from an operations perspective: how long refunds stay available, how much can be refunded, what to do on failure, when funds settle, whether they can be withdrawn, and how to unfreeze them.
For the distinction between refunds and chargebacks, see the refund and dispute handling guide. This article focuses on concrete domestic channel operating rules.
1. The Refund Time Window
Every domestic channel imposes a window on refund requests: orders beyond the window cannot be refunded through the interface, leaving only manual negotiation or a bank transfer. Window lengths differ by channel and change over time, so always confirm against the channel's current official rules rather than assuming.
Operationally, turn the window into a system constraint:
- Compute a refund deadline from the payment time and show it on the order detail page;
- Route orders approaching the deadline into a pending queue with reminders;
- Hide the refund button once the window closes and replace it with a contact support entry.
Skipping this produces situations where support promises a refund the system cannot execute, which becomes a complaint.
2. Partial and Repeat Refunds
Partial refunds are unavoidable: a user returns one item, cancels one subscription month, or asks for the difference after shipping is deducted. Three constraints apply:
Cumulative cap. The sum of multiple refunds on one order cannot exceed the original amount. The system must validate that already refunded amount plus the current amount does not exceed the order total.
Independent refund numbers. Each refund needs its own merchant refund number, never reused. Reuse triggers channel-side idempotency and returns the previous result.
Independent state. The order's refund state should be none, partial, or full rather than a boolean. Systems that store only a boolean cannot correctly display the payable amount after a partial refund.
A practical recommendation: store refund amounts in integer minor units, consistent with order amounts. Floating point accumulation eventually produces cases where one cent cannot be refunded.
3. Six Refund Failure Types and Handling
| Failure type | Typical cause | Handling |
|---|---|---|
| Insufficient balance | Merchant available balance too low | Retry after settlement lands |
| Exceeds refundable amount | Cumulative refunds hit the cap | Review refund detail and fix the logic |
| Window exceeded | Order too old | Escalate to manual negotiation |
| Original transaction not found | Wrong order number or wrong channel | Verify the order-to-channel mapping |
| Transaction not successful | Original order unpaid or closed | Validate payment state up front |
| Risk interception | Abnormal refund frequency or size | Supply materials and contact the channel |
Insufficient balance deserves the most attention: it means refund capacity depends on how much money sits in the channel account. A high-volume day combined with pending settlement can make refunds impossible exactly when they are most needed. Mitigate by keeping a channel balance buffer or confirming whether the channel offers a dedicated refund credit line.
4. Settlement Cycles and Settlement Accounts
Settlement is the channel paying transaction funds into your settlement account after deducting fees. Three rules matter:
- Settlement cycle. Domestic channels commonly settle T+1, the next day after the transaction date, deferring across holidays. New merchants may be placed on extended cycles as risk control.
- Settlement amount does not equal transaction amount. Fees are deducted, and refunds, disputed amounts and penalties may also be withheld.
- The settlement account must belong to the merchant, either a corporate account or the legal representative's account. A name mismatch causes settlement failure or triggers risk review.
Operations should maintain a settlement ledger: the date, amount, fees, corresponding transaction range and arrival time of every settlement. That table underpins revenue recognition and is the basis for detecting a settlement that should have arrived but did not.
5. Withdrawals and Fund Freezes
On some channels settlement funds land in an account balance that must be withdrawn to a bank card. Withdrawals carry per-transaction and daily limits, possible withdrawal fees or minimum amounts, and arrival times that differ from initiation times.
Fund freezes typically stem from four causes: risk review such as abnormal transactions or high complaint rates, qualification problems such as expired licenses or mismatched categories, non-compliant operation such as out-of-scope or prohibited goods, and unresolved disputes.
The general unfreeze path is to confirm the cause, supply materials, submit an appeal, and wait for review. The lesson is not to wait for a freeze before preparing materials. Business licenses, scenario evidence and product page screenshots should be archived in advance so they can be submitted immediately.
6. Consumer Complaints and Disputes
Domestic payments lack a card network chargeback system. Instead there are in-platform transaction complaints plus consumer association and regulatory channels. The recommended order:
- Respond within 24 hours of a complaint, acknowledging and clarifying the request;
- Verify the order and delivery or service evidence;
- Refund immediately when the responsibility is yours, without delay;
- When it is not, provide complete evidence to the platform;
- Keep a full trail of communications and conclusions.
Merchants with high complaint rates face feature restrictions and even termination, so complaint handling is not only a support issue but also channel relationship maintenance.
7. Six Common Mistakes
First, treating refunds as synchronous, when they are asynchronous and require notification or active query to confirm. Second, using the order number as the refund number, which collides on repeat refunds. Third, ignoring the time window, which looks fine early and explodes after six months of operation. Fourth, keeping no channel balance buffer, so refund failure rates spike after promotions. Fifth, running the settlement ledger manually, where one discrepancy takes three days to trace. Sixth, treating freezes as freak events, with unprepared materials stretching unfreeze to weeks.
8. Operations Checklist
Refund windows are enforced in the system with deadline reminders; refund numbers are independent and unique; cumulative refund amounts are validated before submission; order refund state supports three values; failed refunds route into queues by type; the settlement ledger is generated automatically and matched against bank arrivals; withdrawal limits and fees are confirmed; merchant qualification documents are archived with expiry reminders; complaints have a 24-hour response commitment; refunds and settlement are included in the end-of-day process.
For reconciliation specifics, see the reconciliation and bill download handbook. The WeChat Pay refund endpoints appear in WeChat Pay APIv3 integration in practice, the Alipay side in Alipay Open Platform integration, and settlement design under splitting in aggregate payment and the service provider model. More options are collected under the Payment category.
Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow pay.weixin.qq.com and related official documentation and contract terms.