Understanding the WP Sell Services order lifecycle in detail is worth the time whether you are a marketplace owner, a vendor setting up their first listing, or an admin handling a support escalation. Every order goes through the same sequence of states. Each state has a different set of available actions for vendor, buyer, and admin. Getting this flow into your head prevents the most common confusion that new marketplace users run into.
This guide walks each state in order, explains what triggers the transition, and notes the automated actions the platform takes at each step.
The six main order states
Every WP Sell Services order moves through some or all of these states in this sequence:
- Pending Payment
- Waiting for Requirements
- In Progress
- Delivered (shown as Pending Approval while the buyer reviews)
- Revision Requested (optional loop back from Delivered)
- Completed
A few more states cover the exceptions: On Hold, Late, Disputed, Cancellation Requested and Cancelled. A cancelled order can exit the sequence from any active state. An auto-completion can trigger from Delivered if the buyer does not act within the configured window.
State 1: Pending Payment
The order is created at checkout and waits here until the payment clears. Once it does:
- The vendor receives a notification: “New order received for [service name].”
- The buyer receives an order confirmation with a link to their order detail page.
- The order advances to Waiting for Requirements.
The vendor cannot submit a delivery in Pending Payment or Waiting for Requirements states. The buttons are not available. This prevents vendors from pre-delivering work before the buyer has provided the brief.
State 2: Waiting for Requirements
This is the holding state while the platform waits for the buyer to fill the intake form. The delivery countdown timer has not started yet. The buyer’s clock is running instead.
What the buyer sees: their order detail page prominently shows the requirements form with a progress indicator and an explanation that work begins once they submit.
What the vendor sees: their orders dashboard shows the order flagged as “Waiting for Requirements” with the buyer’s last-active timestamp. They cannot take action on the order until requirements land.
Automated behavior during this state:
- Reminder emails go to the buyer 1, 3 and 5 days after purchase if the form has not been submitted
- Admin can see all orders stuck in this state from the admin orders view, useful for identifying buyers who may need a direct nudge
When the buyer submits the form, the state changes to In Progress instantly. The vendor receives a notification and the delivery timer starts.
State 3: In Progress
The delivery countdown is running. The vendor has the buyer’s requirements and can now work.
During In Progress, both parties can send messages in the order-scoped thread. This is the built-in messaging system attached to the order - not email, not a separate chat plugin. Messages are permanent, timestamped, and visible to admin if the order escalates.
Common uses for the In Progress message thread:
- Vendor asks a follow-up question about a specific requirement
- Buyer sends additional reference files they forgot to include in the form
- Vendor shares a work-in-progress preview for early feedback
- Both parties confirm a small scope adjustment
All of these conversations stay attached to the order. When the delivery arrives, both parties can scroll back through the thread to verify that any mid-project adjustments were agreed.
The buyer cannot request a revision or close the order during In Progress. Only the vendor has active controls: they can send the delivery or message the buyer.
State 4: Delivered
The vendor submits a delivery by uploading files and writing a delivery note from their vendor dashboard. The order moves to Delivered, shown as Pending Approval, and:
- The buyer receives a notification: “Your order has been delivered.”
- The buyer’s response window opens - the configured number of days to review the delivery.
- A countdown appears on both the vendor and buyer views showing the auto-complete deadline.
The buyer has three actions in Delivered state:
1. Mark complete. The buyer is satisfied. The order moves to Completed immediately. The vendor’s share is credited to their earnings, held for any clearance days you set, and the review window opens.
2. Request revision. The buyer identifies something that needs to change within the agreed scope. The order moves to Revision Requested with a revision note. The revision count is tracked against the number included in the package.
3. Do nothing. If the buyer does not act within the configured auto-complete window, the order completes automatically. This is a critical protection for vendors - a buyer who disappears after delivery cannot hold a completed order hostage indefinitely.
What counts as a valid revision request
The revision system is not a free rework channel. A buyer can request a revision for work that does not match what was agreed in the requirements form and the In Progress message thread. Requests for new scope (“actually, can you also add a Spanish version?”) should be handled as a new order.
As a marketplace owner, your service terms should define what constitutes a revision vs. a new request. WP Sell Services tracks the revision count per order, and vendors who see a pattern of excess revision requests can document it in the order thread.
State 5: Revision Requested (loop)
When the buyer requests a revision, the order moves to Revision Requested and the vendor receives the revision note. The vendor sees:
- The original requirements form responses
- The full message thread including the buyer’s revision request
- The files already delivered (as reference)
- Which revision number this is out of the included package count
The vendor works the revision and submits a new delivery. The order returns to Delivered and the review window resets.
The revision loop can run multiple times within the included revision count. If the package includes 2 revisions and the buyer has used both, the vendor is not obligated to accept additional revision requests as part of the original order. The order thread is the record of this.
State 6: Completed
An order reaches Completed either when the buyer clicks “Mark Complete” or when the auto-complete timer fires. Once Completed:
- The order is closed and no further deliveries or revision requests can be submitted
- The review window opens - the buyer can leave a star rating and written review
- The vendor’s share is credited, then held for any clearance days you set before it becomes withdrawable
The review can only be submitted after completion. WP Sell Services does not allow reviews on in-flight orders. This prevents the review-as-leverage pattern where a buyer threatens a negative review during a dispute over revision scope.
Auto-complete: how to configure it
The auto-complete window is configured under your marketplace settings. Common configurations:
| Marketplace type | Auto-complete window |
|---|---|
| Quick digital services (voiceover, short copy) | 3-5 days |
| Mid-size projects (logo, short video) | 7 days |
| Extended projects (web development, consulting) | 14 days |
Set it based on how long a reasonable buyer in your niche takes to review a delivery. Too short and buyers feel rushed. Too long and vendors wait an unreasonably long time for completed orders to clear.
Summary: who can do what in each state
| State | Vendor can | Buyer can |
|---|---|---|
| Pending Payment | View order | Complete payment |
| Waiting for Requirements | View order, message buyer | Submit requirements form, message vendor |
| In Progress | Submit delivery, message buyer | Message vendor |
| Delivered | View delivery, message buyer | Mark complete, request revision, message vendor |
| Revision Requested | Submit delivery, message buyer | Message vendor |
| Completed | View, leave review | Leave review |
A note on disputes
Disputes can be opened by either party from any active order state (In Progress through Delivered). When a dispute opens, the order moves to Disputed and admin receives a notification.
The dispute review screen shows: the requirements form, the full message thread, every delivery in chronological order, and the revision history. Admin resolves the dispute from this context with one of five outcomes: a full refund, a partial refund, a ruling in favour of the vendor, a ruling in favour of the buyer, or a mutual agreement. The order thread is the record that makes fair resolution possible, which is why keeping communications in the order thread rather than email is worth reinforcing with your vendors.
For a closer look at how to set up the requirements form that kicks off this lifecycle, see our guide to collecting requirements before work starts.