Trade Management
The trade domain is the most-used part of the Admin App: querying and handling all nine order types can be done on the phone, including on-call operations such as initiating refunds, closing orders, manually handling abnormal orders, and resending notifications.
Common Interactions
Every order page follows the same interaction habits — learn one and you know them all:
- List: pull down to refresh, slide up to load more; cards directly show key info such as the order number, status, and amount, with the failure reason printed right on the card;
- Filter: a draggable floating filter button sits at the bottom-right; tap it to open a bottom drawer and set conditions (keyword, status, time, etc.); the button carries a red-dot reminder when conditions are active;
- Detail: tap a card to open the detail page; the info is grouped into "basic info / amounts and times / merchant and channel", and order-number fields are one-tap copyable;
- Actions: the bottom of the detail page is the action bar — with a single action the button shows directly, with several it opens a picker; dangerous actions (close, ignore) are red; every write action pops a confirmation to avoid mis-taps on the phone;
- Refresh chaining: after completing an action (e.g. a refund) on the detail page and returning, the list silently refreshes itself — no manual pull needed.
Transaction Analysis
Four time filters: last 7 days / last 30 days / this month (the 1st through today) / custom date range.
Six overview metrics: transaction amount, transaction count, refund amount, refund count, payment success rate, average order value. Note the two derived definitions: payment success rate = successful count ÷ total order count; average order value = transaction amount ÷ successful count (-- when there are no successful orders).
Eight chart cards:
| Chart | Use |
|---|---|
| Trade trend | Line chart, toggle between amount / count |
| Pay method share | Donut chart, share of transaction amount |
| Channel success rate | Horizontal bars in descending order, below 90% in red — start here when investigating channel failures |
| Hourly distribution | 24-hour transaction distribution |
| Amount range distribution | Counts per price band |
| Refund trend | Refund amount / count toggle |
| Merchant ranking | Top 10, badges for the top three |
Payment Trades
A payment trade is the core fund-layer document, showing the final state of every payment.
- List: filter by keyword (trade number / merchant order number), fund status, and time; six states (initialized / in progress / success / failed / closed / revoked). The list has an Export button: pick a start and end time spanning no more than 90 days and export to Excel;
- Detail: identity card + large amount + failure reason; trade info (platform trade number / merchant order number / business number / title / currency), amount and payment info (refundable balance, pay method, payment / close / creation time), merchant and channel info (merchant number / channel merchant number / buyer identifier);
- Actions (shown dynamically by permission and state):
- Initiate Refund: available only in the success state with a refundable balance; in the dialog, fill in the refund amount and reason; the amount is validated as 0 < refund ≤ refundable balance;
- Sync Status: queries the latest state from the channel and writes it back;
- Close Order: non-terminal orders only, red, with a second confirmation.
Order Query (Normal / Gateway)
Normal orders and gateway orders are business-layer container documents, in a one-to-many relation with payment trades.
- Normal Orders: five states (pending payment / paid / failed / closed / expired); detail actions: refund (paid with a refundable balance), sync, close (pending payment only);
- Gateway Orders: one extra state, "paying"; the detail has no refund entry — refund gateway orders from the payment trade page or the refund order page; the closable states are pending payment / paying.
Refund Orders
- List: filter by refund number / merchant refund number + status (in progress / success / failed / closed); cards carry the refund reason and failure reason;
- Detail: the refund amount shown in large danger-colored text; includes the original amount, original trade number, channel refund number, etc.;
- Actions: Sync Status only — refunds are fund operations; on the phone only verify the status, and initiate new refunds from a payment trade detail.
Transfer Orders
- List: filter by transfer number + channel (WeChat / Alipay / Douyin) + status;
- Detail: transfer info, channel info (channel transfer number / related number), merchant info;
- Actions (in-progress state only): sync, close (red).
Allocation Orders
- List: filter by allocation number + status (in progress / success / partially successful / failed) + channel;
- Detail: allocation info, original trade info, channel info, plus the allocation detail timeline — receiver type / account / name / amount / result / completion time for each share; when "partially successful", see here which receivers failed;
- Actions: Sync only (in-progress state).
Fund Flow
Fund flow is a read-only ledger: records of how each collection / refund affects the merchant's available funds, filterable by trade number, business number, refund number, and record type (collection / refund). The detail page has no action buttons — flow records derive from trades and are not maintained separately.
Abnormal Order Handling
Abnormal orders are the focus of on-call scenarios: a terminal-state order receives a success callback from the channel (paid after close / paid after fail / paid after cancel); the system cannot decide whether to book the funds, so it waits for a human call.
- List: filter by trade number / business number / abnormal type / processing status (pending / confirmed success / ignored);
- Detail: abnormal info, channel info (including the channel-side status and callback time), merchant info, and the raw channel callback message (formatted JSON, expandable and scrollable — verify the channel-side truth here); when already handled, the handler and handling time are shown;
- Handling actions (pending state only):
- Confirm Success: a strong-confirmation dialog prompts you to verify the channel status first; once confirmed, the order is booked as success;
- Ignore: red; once confirmed there are no more reminders, and the order keeps its original state.
Verify before acting
Both actions are irreversible. Check the channel callback message and channel status in the detail first, then decide whether to book or ignore.
Callbacks and Notifications
Channel Callback Records
The raw callback ledger of channels notifying the platform: filter by trade number, channel trade number, channel merchant number, merchant number, callback type (payment / refund / transfer / allocation), payment product, and processing status (success / failed / closed / ignored / abnormal / unmatched). The detail shows the raw channel message (formatted JSON, collapsed by default, tap to expand, copyable) — start here for issues like "the channel says success, but the platform did not book it".
Merchant Notification Push
The ledger of notifications the platform pushes to merchant systems:
- List: filter by business number, merchant number, event code (e.g.
pay.success), message format, and send result; cards show the send count and the next push time; - Detail: callback URL, send info (send status / count / backoff delay count / next push time), notification content (expandable, copyable JSON), and the send record timeline (latest 50: request count per send, success / failure, HTTP status code, error info; tap for the request summary);
- Resend: a fixed bottom button; after confirmation it immediately sends once more — when a merchant reports a missing callback, verify the address and message, then push again manually.
Related Links
- Merchant App Trades and Refunds: order query and refunds from the merchant perspective
- Payment Order Management / Refund Management: order semantics in detail
- Admin App Feature Map