Abnormal Orders and Fund Flow
These three pages are trade-side verification tools: Abnormal Orders handles special cases where order status and funds disagree, Fund Flow provides a per-record view of fund movements for reconciliation, and Unipay API Logs record the audit details of merchant API calls.
Abnormal Orders
Entry: Trade Orders → Abnormal Orders (both panels can view; the Confirm Success / Ignore actions are available on the admin panel only — merchant-panel users who spot an abnormal record should contact the platform)
What is an abnormal order
An order becomes abnormal when its final status on the channel side disagrees with the local status. The typical case is paid after close: the user scans the QR code but does not pay for a long time; the platform closes the order per the timeout rule, but the user then completes the payment on the original QR code — the channel received the funds, while the local order is "closed".
| Abnormal type | Description |
|---|---|
| Paid after close (close_paid) | Order closed, but the channel received the funds |
| Paid after fail (fail_paid) | Order marked failed, but the channel received the funds |
| Paid after cancel (cancel_paid) | Order cancelled, but the channel received the funds |
Abnormal orders are discovered from three sources: channel callback (callback), manual / auto sync (sync), and scheduled jobs (job).
Handling
Query conditions: fund trade number, merchant order number, abnormal type, discovery source, processing status, channel order number.
Operations:
| Operation | Condition | Description |
|---|---|---|
| View | — | Detail drawer: channel status, handler / time / remark, raw callback message (both panels) |
| Confirm success | Pending | After manually verifying that the funds actually arrived, correct the order to the success state (admin panel only) |
| Ignore | Pending | Decided that no action is needed (e.g. duplicate notification, amount mismatch already settled offline) (admin panel only) |
Verify before acting
Confirm success corrects the order to paid, writes a fund-flow record, and sends the payment-success notification again. Before acting, reconcile with the channel side and confirm that the funds actually arrived.
Fund Flow
Entry: Trade Orders → Fund Flow
Fund flow records individual fund movements (one collection per payment trade + possibly multiple refunds); it is the base data for reconciliation.
Query conditions: creation time (required for export, 90 days max per export), fund trade number, merchant order number, refund order number, record type (collection / refund), channel order number, merchant.
List columns: trade number, record type, merchant order number, amount, title, merchant, channel order number, completion time.
Operations: view (read-only details), export (export per the query conditions; the creation time range must be set first).
Reconciliation tips
Regularly (e.g. daily) export fund flow by time range and reconcile amounts and counts against channel statements; when discrepancies appear, investigate with the Abnormal Orders page.
Unipay API Logs
Entry: merchant panel — Trade Orders → Unipay API Logs; admin panel — System → Logs → Unipay API Logs (same capability, cross-merchant view).
Records every call the merchant makes through the unipay open APIs (request ID, endpoint, latency, client IP, error message) — the first stop when troubleshooting "why does the API return an error".
- Request parameters and response messages in the details are redacted at write time and can be viewed directly;
- Filter by request ID, API path, trace ID, and call status;
- Read-only page: logs cannot be deleted or modified.
Related Sections
- Payment Order Management: the order and trade layers
- Callbacks and Notifications: callback chain troubleshooting