Refunds

Detecting Silent AliExpress Refunds: FINISH and BUYER_ACCEPT_GOODS

AliExpress reports refunds in various ways. Most dropshippers are familiar with explicit refund statuses like REFUND_SUCCESS or TRADE_CLOSED where the end_reason clearly indicates a refund. However, AliExpress also processes refunds without explicitly stating 'refund' in the end_reason, particularly when an order is partially or fully refunded but the order itself isn't fully closed due to other items in the same order, or when the refund is processed directly between buyer and seller outside the standard dispute flow.

These 'silent' refunds can lead to missed refund opportunities or incorrect inventory reconciliation if you're not specifically looking for them. This article outlines how to identify these less obvious refund scenarios using Fetch Order Tracking data fields.

Understanding AliExpress Order Status Fields

Before diving into detection methods, let's review the key AliExpress order status fields Fetch Order Tracking pulls into your Google Sheet:

• order_status: The primary status of the entire order (e.g., FINISH, WAIT_SELLER_SEND_GOODS).
• logistics_status: The current shipping status of the order (e.g., SELLER_SEND_GOODS, BUYER_ACCEPT_GOODS).
• end_reason: A descriptive reason for the order's final status or closure (e.g., REFUND_SUCCESS, TRADE_CLOSED, BUYER_ACCEPT_GOODS).
• gmt_refund: The timestamp when a refund was processed. This is crucial for detecting all types of refunds.

The challenge with silent refunds is that order_status and end_reason might not explicitly shout 'REFUND'.

Scenario 1: Refunded Orders with end_reason as FINISH or BUYER_ACCEPT_GOODS

Sometimes, an order will show an end_reason of FINISH or BUYER_ACCEPT_GOODS, but a refund has still been processed. This often happens if a partial refund was issued, or if the refund was processed after the buyer received and accepted the goods, perhaps due to a quality issue that wasn't a full return.

Detection Method: Cross-referencing end_reason with gmt_refund

To catch these, you need to look for orders where:

1. The end_reason is either FINISH or BUYER_ACCEPT_GOODS.
2. The gmt_refund field is not empty.

If gmt_refund contains a timestamp, it indicates a refund occurred, regardless of the end_reason. The end_reason might simply reflect the overall order state (e.g., 'finished' because all items are delivered and accepted, even if one was refunded).

Always treat a non-empty gmt_refund timestamp as a definitive indicator of a refund, even if other status fields seem contradictory. AliExpress's API reports the actual refund time, which is the ultimate truth.

Example in Google Sheets:

You could use a filter or a formula like this in a helper column:

=AND(OR(C2="FINISH", C2="BUYER_ACCEPT_GOODS"), NOT(ISBLANK(D2)))

Where C2 is your end_reason column and D2 is your gmt_refund column. This formula would return TRUE for orders that fit this silent refund profile.

Scenario 2: Partial Refunds on Multi-Item Orders

If an AliExpress order contains multiple items, and only one item is refunded, the overall order_status for the entire order might not change to a refund-specific status. It might remain FINISH if the other items were delivered successfully, or even WAIT_BUYER_ACCEPT_GOODS if other items are still in transit.

Detection Method: Relying Solely on gmt_refund

In these complex multi-item scenarios, the most reliable indicator of any refund activity is always the gmt_refund field. If any part of the order has been refunded, this field will be populated with a timestamp.

Key takeaway: When analyzing your orders, prioritize the gmt_refund field above all else for refund detection. If it's populated, a refund has occurred for at least part of that order, irrespective of the order_status or end_reason.

Workflow Integration for Refund Detection

To effectively catch all refunds, including these silent ones, integrate the following into your Fetch Order Tracking workflow:

1. Automated Filtering/Conditional Formatting

   Set up conditional formatting in your Google Sheet to highlight rows where the gmt_refund column is not empty. This provides an immediate visual cue for any refund activity.

2. Dedicated Refund Review

   Regularly filter your sheet to show all orders where gmt_refund is populated. For these orders, manually review the end_reason and order_status to understand the specific context. For example, if end_reason is FINISH but gmt_refund is present, it's likely a partial refund or a refund processed after delivery.

3. API-Driven Reconciliation

   If you're using Fetch Order Tracking's API, build logic into your system that checks for the presence of gmt_refund in every order object. This ensures no refund is missed, regardless of the order_status or end_reason.

By proactively monitoring the gmt_refund field in conjunction with order_status and end_reason, you can ensure you're detecting all AliExpress refunds, optimizing your dropshipping profit margins, and maintaining accurate financial records.

For more advanced tracking and refund detection capabilities, explore Fetch Order Tracking at fetchorder.com.

---