Why are WooCommerce orders completing before I ship them?
Usually it is the cart, not a bug. WooCommerce's own status guide says all orders require processing except those in which all products are both virtual and downloadable, so a downloads only order never waits in Processing. Payment gateways and any automation you added can also set a status, so check what was actually on the order.
Rule out the product settings first
Open the completed order at WooCommerce > Orders.
List the products on it.
Open each product and look at the Virtual and Downloadable checkboxes.
If every line is both virtual and downloadable, WooCommerce does not require the order to pass through processing.
If any line is a physical product, the cause is elsewhere.
A single physical item in the cart is enough to keep an order in Processing, so mixed carts are the case worth checking closely.
The usual causes, in order of likelihood
| Cause | What you would see | What to do |
|---|---|---|
| Virtual, downloadable cart | Order completed with no Processing step | Expected. Check the Virtual and Downloadable boxes on physical products |
| Payment gateway behaviour | Status moves on payment confirmation | Check the gateway's own status settings |
| Automation you installed | Status changes on a schedule or a rule | Review whatever you added to auto-complete orders |
| A bulk status change | A block of orders completed at the same minute | Bulk actions on the Orders screen can set Completed |
What it costs you
Completed is defined as fulfilled and complete, and it is the status change that sends the customer email. An order that auto-completes emails the buyer before you have touched it. It also drops out of your Processing filter, so the packing queue you work from no longer contains the order you still owe.
Then ask the payment gateway
WooCommerce is explicit that an order on On hold may transition on its own depending on the payment gateway, and offline methods are assigned On hold pending manual verification. So the second place to look is the gateway's own settings, where the status it sets on a confirmed payment is usually a configurable choice rather than a fixed one.
Keep a queue you can trust
If you cannot stop the auto-completion, stop depending on Processing alone. Some stores sell a genuinely mixed catalogue, and for those the working answer is a shipping queue built from the orders that contain physical items, filtered outside the status column rather than by it.
Key takeaways
- Orders whose products are all virtual and downloadable auto-complete without Processing.
- Offline payment methods land on On hold, and gateways can move status on their own.
- Completed triggers the customer email, so auto-completion notifies buyers early.
- Order notes record the status change, which is the fastest way to find the cause.
A queue that does not depend on one status
I'd Ship That for WooCommerce is in early access. We pull processing and on-hold orders into The Workbench, so an order that auto-completed before you shipped it is not what we treat as the queue. Work what arrives, rate shop USPS and UPS, and buying the label writes the tracking number and provider back to the order with a customer-visible note, even where the status was already moved for you.
Related questions
The behaviour follows the product settings, so the lever is the product. If an item is physical, it should not be marked Virtual or Downloadable. Orders containing a physical line stay in Processing awaiting fulfilment.
On hold means the order is awaiting payment confirmation, with stock already reduced, and it is what offline payment methods use. The order may then move on its own once the gateway confirms, depending on the gateway.
Stock comes down when the order reaches Processing, not at completion, and it is restored if the order fails or is cancelled. So an early completion changes what your queue shows and what the buyer is told, rather than your inventory count.
Only the two effects above: the customer email has already gone, and the order is out of your Processing list. Both are workflow problems rather than data problems, and both are solved by working from a queue that tracks what has a label rather than what has a status.