Refunds

The four AliExpress refund states and what each one means

"Refunded" sounds simple. It is not. On AliExpress, a refund is not a single flag you can read off one field — it is a small state machine, and where an order sits in that machine decides whether you have your money, whether you owe your buyer, and what you should do next.

Treat all of them as one bucket and you will either pay out twice or chase money that is already on its way back to you. Here are the four states that actually matter, what each means for your sheet and your cash, and the move each one calls for.

1. Refund Processing

The buyer (or you) has requested a refund and AliExpress has accepted the request, but the money has not moved yet. In the API this is the in-flight stage — an open issue_status with no completed gmt_refund_payment_finish timestamp.

What it means for you: do not act on the cash yet. The amount is contested but not settled. The mistake here is closing the row too early, marking it refunded, and then having the refund fall through — leaving your books out of sync with reality.

• Sheet: flag as pending refund, keep watching.
• Cash: no change yet.
• Move: re-check on the next sync; do not refund the eBay buyer pre-emptively.

2. Refunded

The money has actually been returned. This is the state where gmt_refund_payment_finish is populated — the refund has completed and the AE order amount has come back to your account.

What it means for you: the cost of this order is now zero (or partial). If you also need to refund your eBay buyer, this is your green light. If the buyer received the item and you still got refunded, that is a different and more profitable problem — but it is also a terminal state, so the row should leave your active queue.

Refunded is a terminal status. An order here should never be re-fetched on the next batch — it is done, and re-checking it just wastes a tracking call.

3. Cancelled

The order was killed before fulfilment completed — out of stock, a price problem, a duplicate, or a request before dispatch. Cancelled and Refunded often overlap (a cancellation usually triggers a refund), which is exactly why a naive single-field check gets confused.

The tricky case is a Cancelled status on an order that already shows Delivered. That is not a bug — it is a delivered-then-refunded order, and it needs to be modelled deliberately. We break that scenario down in why your refund column shows Cancelled for a delivered order.

• Sheet: mark terminal, remove from the working set.
• Cash: usually refunded — confirm against the finish timestamp.
• Move: decide whether the eBay side needs re-sourcing or a buyer refund.

4. Dispute

The buyer opened a dispute and the outcome is undecided. This is the state most likely to hide, because some disputes never touch the obvious refund fields and instead surface in places like end_reason or on child orders. A dispute can resolve in your favour, partially, or fully against you — so until it closes, the money is genuinely uncertain.

What it means for you: this is the row to actively manage, with delivery proof ready. Disputes that quietly settle without you noticing are how refunds slip past your books. For the silent ones, see detecting refunds AliExpress reports as silent end_reasons.

Why one field is never enough

Here is the core trap: there is no single "refund state" field on an AliExpress order that captures all four cleanly. The truth is spread across issue_status, the gmt_refund_* timestamps, child orders, and end reasons. Read only one and you will miss whole categories of refund — especially disputes and partial returns.

This is exactly the problem Fetch Order Tracking was built to solve. Its refund detection checks issue_status, the gmt_refund_* fields, and child orders together — not one field in isolation — so a delivered-then-refunded order or a silent dispute actually shows up in your sheet instead of vanishing. Each order is mapped to a clean refund state and, once it reaches a terminal one like Refunded or Cancelled, it drops out of the re-fetch queue so your batches stay fast.

Refunds are where dropshipping margins quietly leak. Get the four states right and you stop guessing about your own cash. Try Fetch Order Tracking and let every refund land in the right column, automatically.

Frequently asked questions

What is the difference between Refund Processing and Refunded on AliExpress?

Refund Processing means AliExpress has accepted the refund request but the money has not actually moved, which in the API shows up as an open issue_status with no completed gmt_refund_payment_finish timestamp. Refunded means the money has been returned and that finish timestamp is populated. The practical rule is simple: only act on the cash once it reaches Refunded, because acting on Refund Processing risks closing a row that later falls through.

Why does my AliExpress order show Cancelled and Refunded at the same time?

Cancelled and Refunded frequently overlap because a cancellation usually triggers a refund, which is exactly why a single-field check gets confused. The harder case is a Cancelled status on an order that already shows Delivered, which is a delivered-then-refunded order rather than a bug. Both are terminal, so the row should be marked done and removed from your working set rather than re-checked.

How does Fetch Order Tracking detect refunds that hide in a dispute?

Disputes are the state most likely to hide because some never touch the obvious refund fields and instead surface in end_reason or on child orders. Fetch Order Tracking checks issue_status, the gmt_refund_* timestamps, and child orders together rather than reading one field in isolation, so a silent dispute or a partial return actually shows up in your sheet. Once an order reaches a terminal state like Refunded or Cancelled it drops out of the re-fetch queue so your batches stay fast.

Related guides

• Why your refund column shows Cancelled for a delivered order
• Detecting refunds AliExpress reports as silent end_reasons
• Refund detection beyond gmt_refund_payment_finish

---