Guide

End-to-end test: simulating a full eBay to AliExpress order lifecycle

May 13, 2026 · 7 min read

Key takeaways

The failure modes in eBay and AliExpress dropshipping are silent, so the only reliable way to trust your pipeline is to push one test order through every stage on purpose.
Walk a single low-value order through six stages — sale, sourced, awaiting dispatch, shipped, delivered, refunded — and confirm the expected field lands at each step.
The refund stage is the real exam: a refund that arrives after a Delivered status is the classic leak, and catching it means checking issue_status, the gmt_refund timestamps, and child orders together.
One order proves correctness; a batch proves the pipeline survives volume without looping, hitting rate limits, or re-fetching terminal rows.
Running the test through Fetch Order Tracking means the pipeline you validate is the same batch-processing, skip-list pipeline you keep for live orders.

The worst time to discover that your tracking pipeline drops refunds is during a live dispute, with a buyer's money on the line and an eBay case clock ticking. The best time is on a quiet Tuesday, with one deliberately chosen test order, before any of it matters.

This is a walkthrough for doing exactly that: pushing a single order through every stage of its life — sale, sourcing, dispatch, transit, delivery, and refund — and checking at each step that the right value landed in the right cell. Do this once and you will trust your numbers for the next ten thousand orders.

Why simulate at all?

Because the failure modes in eBay × AliExpress dropshipping are silent. Nothing throws an error when a refund quietly fails to register, or when a 19-digit AE order ID parses where a 16-digit one would not, or when the carrier resolves wrong. The order just sits there looking fine while being wrong. An end-to-end test surfaces those gaps on purpose, in a controlled run, instead of leaving you to find them one painful surprise at a time.

You are not testing whether the happy path works — it almost always does. You are testing what happens at the seams: the refund, the split order, the false Delivered. That is where money leaks.

The six stages to walk through

Take one real, low-value order — something cheap you genuinely intend to ship — and follow it through each stage, confirming the expected field at every step:

Sale on eBay. The order appears. Confirm you are pulling earnings from the Finances API (real net payout after fees), not the Order API's gross price. This is the number your profit column lives on.
Sourced on AliExpress. Place the AE order and attach its order ID to the eBay row. Confirm the AE order date and order_amount get captured.
Awaiting dispatch. Before tracking exists, the row should read a clear pre-ship status — not a blank, not an error.
Shipped. Once a tracking ID lands, confirm the carrier resolves correctly from the tracking-ID prefix, not from the unreliable carrier_name field, and that a status string maps cleanly to Shipped.
Delivered. Confirm the status flips to Delivered and a carrier delivery-proof link is captured — the link that wins Item Not Received cases.
Refunded. The deliberate stress test. Trigger a refund and confirm it is detected even after delivery.

The refund stage is the real exam

Stages one through five usually pass on the first try. Stage six is where most homemade pipelines quietly fail, and it is the only stage worth labouring over.

A refund that arrives after a Delivered status is the classic trap. If your detection only checks the shipping status, a delivered-then-refunded order will read as a completed, profitable sale forever — and you will keep counting money you no longer have. To catch it, the test has to confirm your logic reads more than one field:

issue_status — did a dispute open or resolve?
the gmt_refund_* timestamps — did money actually move back?
child orders — did the refund land on a split line instead of the parent?

If your test order flips to a refunded state across all those checks even though it already showed Delivered, your detection is sound. If it stays green, you have just found the leak — on a Tuesday, for pennies, instead of in a live case for real money.

Run it as a batch, not a single click

One order proves correctness. It does not prove your pipeline survives volume. The second half of the test is throwing a realistic batch at it and watching for the failure modes that only appear at scale:

Looping — does the run re-process rows it already finished, or does a skip-list let it complete in one pass?
Rate limits — does it back off gracefully when AliExpress returns a frequency-limit error, or drop orders mid-batch?
Terminal rows — does it correctly leave delivered, expired, and cancelled-and-refunded orders alone instead of re-fetching them forever?

This is precisely the behaviour Fetch Order Tracking is built around — batch processing with auto-chaining (about 25 orders a click, with a short delay) and a skip-list so a run finishes once rather than looping. When you run your end-to-end test through it, the pipeline you are testing is the pipeline you keep, which is the whole point of testing it.

Make it a habit, not a one-off

Re-run the simulation whenever something changes: new store added, eBay OAuth scopes refreshed, a new carrier in the mix. A five-minute test order is the cheapest insurance you will ever buy against a silent pipeline failure.

To dig into the two stages that catch people out, see our guide on which statuses should map to Shipped and our breakdown of refund detection done properly. When the test passes and you are ready to run it for real, connect your store to Fetch Order Tracking and let the same pipeline handle live orders.

Frequently asked questions

Do I have to spend real money to test my order lifecycle?

You can run most of the test in a sandbox, but the most honest end-to-end check uses one real, low-value order you genuinely intend to ship. A cheap live order exercises the real Finances API payout, the real tracking-ID prefix, and a real refund in a way sandbox data often cannot. Spending a few pennies on a Tuesday is far cheaper than discovering a leak during a live dispute.

Which stage of the lifecycle test is most likely to fail?

The refund stage, specifically a refund that arrives after the order already shows Delivered. If your detection only watches the shipping status, a delivered-then-refunded order reads as a profitable sale forever. The test has to confirm your logic reads issue_status, the gmt_refund timestamps, and child orders, so a refund flips the row even after a Delivered status.

How often should I re-run the simulation?

Re-run it whenever something in the pipeline changes — a new store added, eBay OAuth scopes refreshed, or a new carrier in the mix. A five-minute test order is the cheapest insurance against a silent failure, and running it through Fetch Order Tracking means you are validating the exact batch-processing pipeline you use for live orders.

Related guides

Try Fetch Order Tracking → More guides