Refunds

Refund detection beyond gmt_refund_payment_finish

April 13, 2026 · 7 min read

Key takeaways

Checking only gmt_refund_payment_finish misses any refund that is agreed but not yet paid, partial, or processed against a child order.
Reliable detection evaluates four signals together: the gmt_refund_* family, issue_status, child orders, and order_status plus end reasons.
The most dangerous case is delivered-then-refunded; never key refunded off not delivered, because delivery and refund are not mutually exclusive.
Completed-refund timestamps can land days after delivery, so a one-time check at fulfilment is not enough; orders must be re-examined until terminal.
Fetch Order Tracking checks issue_status, the gmt_refund_* timestamps, and child orders together and re-fetches non-terminal orders each batch.

If your refund detection checks one field, it is wrong. Not occasionally — structurally. AliExpress does not record a refund in a single tidy place. It scatters the evidence across order status, issue records, refund timestamps, and sometimes a child order you did not even know existed. Watch one field and you will catch the obvious refunds and miss the expensive ones.

The field everyone reaches for is gmt_refund_payment_finish — the timestamp set when a refund payment completes. It is real, it is useful, and it is nowhere near sufficient on its own. Here is why, and what to check alongside it.

Why one field is never enough

A refund on AliExpress can live in several stages and shapes at once. gmt_refund_payment_finish only populates when a refund has fully completed as a payment. That leaves a long list of cases it cannot see:

A refund that has been agreed but not yet paid out — the dispute is resolved, the money is coming, but the finish timestamp is still empty.
A partial refund issued through a dispute while the order otherwise looks delivered and fine.
A refund processed against a child order in a split shipment, leaving the parent order looking untouched.
A refund whose only real footprint is an issue_status change or an end-reason buried in the dispute record.

The refunds that hurt are not the loud ones you can see. They are the quiet ones that complete after you have already counted the order as profit.

The four signals to check together

Reliable refund detection is not one lookup — it is a small panel of signals, evaluated together. If any of them fires, the order is suspect.

The gmt_refund_* family. Not just gmt_refund_payment_finish, but the related refund timestamps. A populated start time with no finish still means a refund is in motion.
issue_status. The dispute/issue field reveals refunds that are agreed or in progress before any money moves. This is your earliest warning.
Child orders. When one purchase splits into multiple AE orders, a refund can land on a child while the parent stays clean. You have to walk the children, not just the top-level order.
order_status and end reasons. States like Cancelled, plus the dispute's end_reason, catch refunds that never neatly hit the timestamp fields at all. We dig into those in detecting refunds AliExpress reports as silent end_reasons.

Check all four and combine the result into a single refund state on the row. Miss any one and a category of refunds walks straight past you.

The delivered-then-refunded trap

The single most dangerous case is the order that delivers and then gets refunded. The parcel arrived, the buyer kept it, and a dispute or goodwill refund still clawed your money back. If your sheet keys "refunded" off "not delivered", this order is invisible — it shows delivered, it shows paid, it shows profit. It is none of those things.

This is common enough that it deserves its own column logic. We unpack exactly how to model it in why your refund column shows Cancelled for a delivered order — and the answer is never to assume delivery and refund are mutually exclusive.

Why this matters to your bottom line

Undetected refunds do not just dent one order — they corrupt every number downstream. Your profit column overstates the month. Your "best supplier" rankings are skewed by orders that were quietly reversed. You reorder from a supplier with a refund problem because the data never flagged it. At a few hundred orders a month, even a small slice of missed refunds is real money you think you made and did not.

And because completed-refund timestamps can land days after delivery, a one-time check at fulfilment is not enough. You need orders re-examined as their state evolves — right up until they reach a genuinely terminal status.

How Fetch Order Tracking handles it

Fetch Order Tracking was built around exactly this problem. Its refund detection does not trust a single field — it checks issue_status, the gmt_refund_* timestamps, and child orders together, then writes a clear refund state into your Google Sheet next to the AE order amount. A delivered-then-refunded order is surfaced as refunded, not buried as profit.

Because the tool re-fetches non-terminal orders on each batch run, a refund that completes after delivery still gets caught the next time the order is checked — without you re-reading the whole sheet by hand. The result is a refund column you can actually build decisions on.

If you want refund detection that looks past gmt_refund_payment_finish by default, try Fetch Order Tracking and let the four signals do the watching for you.

Frequently asked questions

Why is gmt_refund_payment_finish not enough on its own?

That field only populates when a refund has fully completed as a payment, so it cannot see refunds that are agreed but not yet paid out, partial refunds on otherwise-fine orders, or refunds processed against a child order in a split shipment. It also misses refunds whose only footprint is an issue_status change or an end-reason buried in the dispute record. Watch only that one field and you catch the obvious refunds while the expensive ones slip past.

Which signals should I check together to catch every refund?

Check four signals as a panel: the full gmt_refund_* family, issue_status, child orders, and order_status plus dispute end reasons. If any of them fires, treat the order as suspect and combine the result into a single refund state on the row. Missing any one of them lets a whole category of refunds walk straight past you.

How do I catch a refund that completes after the order was delivered?

Because completed-refund timestamps can land days after delivery, you cannot rely on a single check at fulfilment; you have to re-examine orders as their state evolves until they reach a genuinely terminal status. Fetch Order Tracking re-fetches non-terminal orders on each batch run, so a refund that completes after delivery is caught the next time the order is checked and written to the refund column without you re-reading the sheet by hand.

Related guides

Try Fetch Order Tracking → More guides