Problems with dropshipping include changing supplier stock, delivery delays, inconsistent product quality, thin margins, and difficult returns. When an individual order stops moving, though, a general list of risks is not enough. Identify the last confirmed event, check the supplier’s record, and separate a refused request from an unknown outcome before you retry or buy a replacement.
This guide focuses on that operational decision. Runner AI publishes it, and the Runner example is based on its order-dispatch source and published dropshipping guide. It is not a customer case study or a promise that software removes supplier risk.
Common problems with dropshipping and what to check
You sell the product, but another business controls stock, packing, and dispatch. That separation leaves you responsible for explaining an outcome you may not yet be able to confirm. A useful first response is to name the missing fact rather than call every delay a shipping problem.
- A variant becomes unavailable. Check the exact supplier variant, quantity, warehouse, and destination. Pause the affected offer or confirm an acceptable alternative before promising it.
- Supplier cost changes. Compare current item and freight costs with the approved retail price. Recheck the margin before accepting more orders.
- A paid customer order has no shipment. Find the supplier order ID, payment status, and dispatch record. Establish whether the supplier has an order and whether it is paid.
- Product quality is uncertain. Compare a sample and its packaging with the listing claims. Verify the item before expanding promotion; a catalog photo is not an inspection.
- A return or cancellation is unresolved. Check the customer refund record and separate supplier confirmation. Keep the financial action separate from stopping the parcel.
Huboo’s overview of dropshipping drawbacks describes the stock, quality, and supplier-communication risks. Those are reasons to test the operating model, not proof that a particular supplier caused your current incident. Use the supplier evaluation guide before choosing a partner, and calculate product costs and margins before scaling an offer.
Trace the order across three separate records
A shopper’s payment, a supplier purchase, and a parcel’s movement are different events. Treating them as one status hides where work stopped.
Start with the store order. Confirm the ordered variants, quantities, delivery details, and actual payment state. An order confirmation email alone does not tell you whether the supplier accepted anything. Preserve the store order number so support can connect the records.
Then check the supplier order. Look for the matching supplier ID, items, destination, payment requirement, and latest update. Check the account connected to your store, not another buyer account. One customer order can produce several supplier orders, so one successful parcel does not settle every item.
Finally, check shipment evidence. A tracking number, label, carrier acceptance scan, and delivery scan each tell you something different. Do not turn a label into a claim that the carrier has the parcel. The fulfilled, shipped, and delivered explanation covers those distinctions.
For example, imagine a shopper pays for two products. One supplier order is paid and processing; the other is created but unpaid. The second item does not need a new purchase. It needs its existing supplier payment resolved. This is an illustrative example, not a reported Runner incident.
Record the latest confirmed event for each supplier order. That gives you a specific question to investigate, such as “Was this order accepted?” or “Has this paid order been dispatched?”, instead of a vague request to make shipping work.
A refused request and an unknown outcome need different actions
A supplier can refuse an order and return an error code with a reason. A request can also time out after the supplier received it. In the second case, a missing success response is not proof that nothing happened. Submitting another order can create a second purchase.
Use this distinction before taking an action that can charge you or send a parcel.
- The integration confirms it stopped before contacting the supplier. This attempt did not reach the supplier. Correct the stated prerequisite and use the supported recovery path.
- The supplier returns a refusal. You have a supplier-reported reason. Preserve the code and message, check for an existing order, and resolve the cause.
- The request timed out or the outcome is unknown. Acceptance has not been established either way. Reconcile the supplier account and ask support to confirm the outcome.
- A matching supplier order exists. There is already an order to manage. Resolve its payment, address, or processing issue rather than creating another.
Runner’s order-dispatch implementation provides a concrete example. Its CJ and AliExpress paths can carry a supplier error code and message with the dispatch outcome. The dispatcher logs the supplier code. That preserves useful diagnostic evidence, but it does not automatically turn the outcome into a confirmed rejection or a safe retry. Some paths still require reconciliation.
This is an implementation example, not a claim that every supplier error appears in a merchant-facing screen. If you contact support, give the store order number, supplier order IDs if available, visible status, and time of the attempt. Ask support to check the supplier response and whether a second submission would duplicate work. Never send API keys or passwords.
Recover the order without creating a second problem
In Runner’s documented connected-account workflow, Runner places the supplier order, but you confirm and pay for it in your supplier account. The shopper paying your store does not pay that separate purchase. Use the fulfillment and recovery instructions for the controls and status-specific actions.
If an outcome is uncertain, stop manual resubmission while it is investigated. Give one person ownership of the resolution. Two operators independently buying a replacement can defeat even a careful automated retry policy. Before switching suppliers, establish what happened to the original order and whether it can still ship.
Keep refunds separate, too. Returning the customer’s money does not by itself cancel a supplier purchase. Confirm cancellation with the supplier, and request any supplier refund through that supplier’s process. Do not promise that a parcel has stopped merely because your store shows a refund.
A customer update should state what is confirmed and when you will next respond. For example, “Your payment is confirmed. We are checking whether the supplier accepted the order. We will update you by [time and date].” Replace the placeholder with a commitment you can meet. Only give a dispatch date when you have evidence for it.
For future orders, evaluate automation by how it handles uncertainty, not just how quickly it imports a product. Runner’s dropshipping automation overview explains the review boundaries. Stock checks, clear supplier IDs, and visible exceptions help an operator act; they do not guarantee delivery, quality, or profit.
Questions about dropshipping problems
What are the main disadvantages of dropshipping?
You depend on a supplier for availability, product quality, and dispatch while customers still expect answers from your store. Shipping costs and returns can also make a seemingly profitable price unworkable. Test a sample and a representative delivery route, calculate the full cost, and agree on exception handling before promoting the product widely.
Why is my customer order paid but the supplier order unpaid?
They are separate purchases. Your customer pays your store; you buy fulfillment from the supplier. In Runner’s documented connected-account workflow, you must confirm and pay for the supplier order in CJ or AliExpress. First verify the existing supplier order and its payment state. Do not create a replacement just because it has not shipped.
Should I retry a failed dropshipping order manually?
Not until you establish whether the supplier already received it. A failure label or timeout can leave the result uncertain. Check the connected supplier account and follow the platform’s recovery instructions. Runner’s guide directs merchants with a failed order to check the supplier account and contact support before placing it manually; an unknown outcome requires reconciliation.
Can automation remove the problems with dropshipping?
No. Automation can move order data and preserve evidence, but it cannot guarantee supplier stock, product quality, delivery dates, or profit. The useful safeguard is a clear boundary between confirmed work, pending work, and work that needs a person. When an outcome is unknown, checking the supplier record is more important than repeating the request.