Refunds

Detecting refunds AliExpress reports as silent end_reasons

May 3, 2026 · 7 min read

Key takeaways

Some AliExpress refunds never touch the obvious refund status or timestamp fields — they only show up in the end_reason field that explains why an order closed.
To catch every refund, read several signals together as an OR: issue_status, the gmt_refund_* timestamps, child orders, and end_reason.
The most dangerous case is the delivered-then-refunded order, which closes with a refund end_reason while your tracking still says Delivered.
Never stop watching an order just because it reached a terminal status like Delivered; keep checking it through its close-out.
Fetch Order Tracking checks all four signals and walks child orders, so a silent refund flips your refund column instead of slipping past it.

Most refund detection looks for the loud signals: a refund status, a refund timestamp, an obvious flag that says "this money came back". Those work for the refunds AliExpress wants you to see. The dangerous ones are quieter.

There is a category of refund that never lights up the fields you are watching. It only shows up in end_reason — the field that explains why an order closed. If you are not reading it, you can have money returned to you and still show that order as a normal, profitable sale. By the time it surfaces in your AliExpress balance, your books have already been wrong for weeks.

Why some refunds go silent

AliExpress closes orders for a lot of reasons, and not all of them route through the same fields. A refund that comes from a dispute, a cancellation after part-shipment, or a system-side close-out may finalize the order with an end_reason that clearly indicates a refund — while the headline status and the obvious refund timestamps stay empty or ambiguous.

From your sheet's point of view, the order just... ended. No drama. If your logic only checks the primary refund fields, that row keeps reporting as if nothing happened.

A silent refund is the worst kind, because it does not look like a problem. It looks like a completed sale right up until you reconcile your balance and the numbers do not add up.

The fields that actually tell the truth

No single field is enough. To catch every refund — loud and silent — you have to read several signals together:

issue_status — flags disputes and problem flows that often resolve as refunds.
gmt_refund_* timestamps — the obvious "money moved back" markers, when they exist.
Child orders — a refund on one parcel of a split order can hide behind a parent that still looks fine.
end_reason — the closing explanation that catches the refunds the other three miss.

Treat these as an OR, not an AND. If any of them indicates a refund, the row is a refund. We covered the broader multi-field approach in refund detection beyond gmt_refund_payment_finish; end_reason is the signal that completes the set.

The case that bites everyone: delivered, then refunded

The nastiest version is the delivered-then-refunded order. The parcel arrives, the buyer (or the dispute system) gets a refund anyway, and the order closes with an end_reason indicating a refund — while your tracking still proudly says Delivered.

If you only check refund status on orders that are not delivered, you will never catch these. You have to keep watching an order through its terminal state, because "delivered" and "you got paid for it" are not the same thing. That single assumption — that a delivered order is a safe order — is responsible for a huge share of the refunds people miss.

How Fetch Order Tracking surfaces them

This is precisely the gap Fetch Order Tracking was built to close. Its refund detection does not trust one field. It checks issue_status, the gmt_refund_* timestamps, and the closing end_reason, and it walks child orders on split sales — so a delivered-then-refunded order flips your refund column instead of slipping past it.

Because everything lands in the Google Sheet you already own, a caught refund is just a value change on the row you were already looking at. No separate dashboard, no reconciliation spreadsheet, no end-of-month surprise. The same engine that keeps your tracking honest keeps your refund column honest too — that is the whole pitch of syncing eBay and AliExpress in one place.

A practical detection checklist

Read end_reason on every order, including delivered ones.
Combine it with issue_status and gmt_refund_* as an OR condition.
Apply the check across all child orders of a compound sale.
Never stop watching an order just because it reached Delivered.
Flip a single, unambiguous refund column so the row is impossible to misread.

Why this is worth the effort

Every silent refund you miss is money you think you have and don't. It distorts your profit per order, hides bad suppliers who quietly issue refunds, and throws off any decision you make from the sheet. Catching them is not bookkeeping pedantry — it is the difference between a profit number you can act on and one that is quietly fiction.

Read end_reason. Read it on everything. And if you would rather not maintain that logic by hand, let Fetch Order Tracking watch all four signals for you so the silent refunds stop being silent.

Frequently asked questions

What is a silent refund on AliExpress?

It is a refund that closes the order without lighting up the fields most people watch — no clear refund status, no obvious refund timestamp. Instead it surfaces only in the end_reason field that explains why the order ended. If your logic checks only the primary refund fields, the row keeps reporting as a completed, profitable sale even though the money already came back.

Which fields should I check to catch every refund?

Read four signals together and treat them as an OR rather than an AND: issue_status for disputes, the gmt_refund_* timestamps for the obvious money-moved markers, the end_reason close-out explanation, and the child orders of any split sale. If any one of them indicates a refund, the row is a refund. Relying on a single field is what lets silent refunds through.

Why does a delivered order still need to be checked for refunds?

Because delivered and paid-for are not the same thing. A parcel can arrive and the buyer or the dispute system can still receive a refund, closing the order with a refund end_reason while your tracking proudly says Delivered. If you only check refunds on orders that are not yet delivered, you will never catch these — so you have to keep watching an order through its terminal state.

Related guides

Try Fetch Order Tracking → More guides