Merchant orders and reconciliation
Merchant Orders has Collection Orders and Product Orders categories. My Orders lists purchases made by the signed-in account. If one account has both roles, check which view you are using.
Find external collections and frozen funds
Open Merchant Center β Orders β Collection Orders and search by TDCloud collection number or your external business reference. Amount-based OpenAPI collections appear here and do not automatically create TDCloud product orders. Storefront sales appear under Product Orders.
Collections show the original currency amount, payment status, TDC settlement amount, hold status and expected release time. Select the business reference to inspect the saved conversion, the amount transferred to available funds, debt or credit repayment, and the stable payment event identifier. Settlement uses amounts saved at creation; payment, release and queries never revalue an old order at current exchange rates.
The page separates available wallet funds, frozen collection funds and the guarantee deposit. A credited but frozen collection is already posted to the wallet and is not yet spendable; do not credit it again. Frozen collection totals exclude the guarantee deposit. Complaints, refunds and debt repayment can affect actual release and final available funds. Test collections carry a test-payment label.
What to inspect for each order
| Information | Purpose |
|---|---|
| Order number, product and quantity | Identify the sale and delivery |
| Buyer payment and currency | Confirm the buyerβs charge, not merchant revenue |
| Status and payment time | Distinguish unpaid, delivery pending, completed and cancelled |
| Merchant revenue and settlement status | Confirm whether the sale generated wallet revenue |
| Revenue transaction number | Match the wallet entry and balance change |
Order counts, sales counters and a Completed label alone do not prove settlement. See Payment and settlement for the amount relationships.
Reconciliation sequence
- Locate the merchant order by order number.
- Check payment status and time.
- Compare product net value with merchant revenue, accounting for discounts, fees and currencies.
- Find the corresponding revenue transaction and its before/after balances.
- Independently confirm delivery and revenue posting.
An order can be paid while delivery is pending. Check fulfillment and financial posting separately.
When a delivery callback is configured
Post-payment business callbacks may arrive more than once. Deduplicate by order number so retries do not activate a service or deliver a product twice. The platform sends a stable header:
Idempotency-Key: order-fulfillment:ORDER_NOThe current body contains order_no and callback_no. This key identifies duplicate delivery; it is not a signature or authentication credential. Establish a trusted source separately instead of delivering merely because this header is present.
Return HTTP 200 to acknowledge success; the current platform does not accept every 2xx status as success. The request timeout is approximately three seconds. For longer work, durably record the task and track its subsequent execution in your service.
Persist the business result before acknowledging success. An external side effect may already have happened before a network failure, so check your own processing record on a repeated request.
Handling exceptions
- Awaiting payment: wait for payment confirmation before delivering.
- Paid, delivery pending: check receiver availability and whether the order was already processed, then observe background retries.
- Cancelled: stop directing the buyer to the old payment link; the record helps trace stock release.
- Paid without revenue: provide the order number and missing revenue details to the platform.
- Delivery mismatch: record what was delivered and when, avoiding duplication between manual handling and automatic retries.
Use the support checklist when reporting issues. Do not send callback credentials or customer passwords.