AliExpress API

What BUYER_ACCEPT_GOODS really means in the AliExpress response

When you read an AliExpress order back through the dropshipping API, the status that feels like the finish line is BUYER_ACCEPT_GOODS. It reads like a clean ending — the buyer got the parcel, the buyer accepted it, you can stop watching. Most automation treats it exactly that way: see BUYER_ACCEPT_GOODS, mark the row Delivered, move on.

That is mostly safe. But "mostly" is the word that costs dropshippers money. BUYER_ACCEPT_GOODS is an order-lifecycle state, and it does not say a single word about whether you got refunded, whether your eBay buyer is the one who received it, or whether a dispute is quietly running in parallel.

What the status literally means

On AliExpress, BUYER_ACCEPT_GOODS is the order_status that follows WAIT_BUYER_ACCEPT_GOODS. It means one of two things has happened:

• The buyer (in dropshipping, that is you, the reseller) confirmed receipt manually, or
• The confirmation window expired and AliExpress auto-accepted on your behalf.

That second case matters more than people expect. A huge share of orders reach BUYER_ACCEPT_GOODS not because anyone clicked "received" but because the timer ran out. The status flips automatically. So BUYER_ACCEPT_GOODS is closer to "the order's acceptance window has closed" than "a happy human confirmed delivery".

BUYER_ACCEPT_GOODS tells you the AliExpress order is settled. It does not tell you the parcel reached your eBay customer, and it definitely does not tell you whether you were refunded along the way.

What it does not tell you

Here is the trap. order_status and refund state are separate dimensions of the same order. An order can sit at BUYER_ACCEPT_GOODS and have been refunded — fully or partially — through a dispute, a child order, or a gmt_refund event. If your sheet only reads order_status, that refunded order looks like a clean, profitable, delivered sale. It is not. Your margin already evaporated and your profit column is lying to you.

This is the delivered-then-refunded pattern, and it is exactly why refund detection cannot be a single-field check. We go deep on it in refund detection beyond gmt_refund_payment_finish, and the short version is: never read order status as proof of payment.

The second blind spot: whose "delivered" is it?

There is a layer the AE status cannot see at all. BUYER_ACCEPT_GOODS describes the AliExpress leg of the journey — supplier to you, or supplier to the forwarding address. It says nothing about the last mile to your eBay buyer's door.

So you can have an AE order proudly at BUYER_ACCEPT_GOODS while the carrier's tracking still shows the parcel sitting at a depot, or marked delivered to the wrong address. If you closed the eBay side on the AE status alone, you have set yourself up for an "item not received" case you will struggle to defend. We cover that exact mismatch in when AliExpress shows Delivered but your buyer disagrees.

How to use the status correctly

Treat BUYER_ACCEPT_GOODS as one input, not the verdict. A robust read combines several fields before it decides a row is truly done:

1. order_status — is the AE order in a terminal accepted state?
2. logistics_status and the carrier's own tracking — has the parcel actually reached the buyer?
3. refund signals — issue_status, gmt_refund_*, and any child orders that quietly returned cash.
4. EDD vs reality — did delivery land inside the window you promised?

Only when those agree should a row go to a clean Delivered. Anything else deserves a second look before you trust it.

Let the fetcher cross-check it for you

Doing this by hand on every order is exactly the kind of tedious cross-referencing that does not scale past a few dozen orders a day. Fetch Order Tracking reads the raw AliExpress response and writes the resolved picture into your Google Sheet — tracking ID, real carrier, tracking status, estimated delivery date, AE order amount, and refund state — so a BUYER_ACCEPT_GOODS order that was secretly refunded does not slip through as profit.

Because the refund check looks at issue_status, the gmt_refund fields, and child orders together — not just one field — a delivered-then-refunded order shows up as exactly that, instead of hiding behind a happy-looking status. That is the difference between a profit column you can trust and one that quietly overstates your month.

If you would rather your sheet interpret BUYER_ACCEPT_GOODS the careful way automatically, try Fetch Order Tracking. It treats the status as the start of a check, not the end of one.

Frequently asked questions

Does BUYER_ACCEPT_GOODS mean the buyer actually confirmed receipt?

Not necessarily. BUYER_ACCEPT_GOODS means either the buyer (in dropshipping, you) confirmed receipt, or the acceptance window expired and AliExpress auto-accepted on your behalf. A large share of orders reach this status simply because the timer ran out, so it is better read as the acceptance window has closed than as a happy confirmation.

Can an order be at BUYER_ACCEPT_GOODS and still be refunded?

Yes, and this is the trap that costs sellers money. The order_status and the refund state are separate dimensions, so an order can sit at BUYER_ACCEPT_GOODS while it was refunded fully or partially through a dispute, a child order, or a gmt_refund event. If your sheet only reads order_status, that refunded order looks like clean profit, which is why refund detection needs more than one field.

Is BUYER_ACCEPT_GOODS proof my eBay buyer received the parcel?

No. The status only describes the AliExpress leg, from supplier to you or to the forwarding address, and says nothing about the last mile to your eBay customer. You can have an AE order at BUYER_ACCEPT_GOODS while the carrier tracking still shows the parcel at a depot or delivered to the wrong address, so always confirm the carrier status before you close the eBay side.

Related guides

• Refund detection beyond gmt_refund_payment_finish
• When AliExpress shows Delivered but your buyer disagrees
• Reading the raw AliExpress order_status and logistics_status fields

---