Guiding a service order from payment to completion

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 order states

Every WP Sell Services order moves through some or all of these states in this sequence:

1. Payment Received
2. Awaiting Requirements
3. In Progress
4. Delivered
5. Revision Requested (optional loop back from Delivered)
6. Completed

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: Payment Received

The order enters this state the moment the payment clears. At this point:

• 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.
• If the listing has an intake form attached, the order immediately advances to Awaiting Requirements. If the listing has no intake form (unusual but valid for very simple services), the order skips directly to In Progress.

The vendor cannot submit a delivery in Payment Received or Awaiting Requirements states. The buttons are not available. This prevents vendors from pre-delivering work before the buyer has provided the brief.

State 2: Awaiting 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 “Awaiting Requirements” with the buyer’s last-active timestamp. They cannot take action on the order until requirements land.

Automated behavior during this state:

• A reminder email goes to the buyer at 48 hours 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 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. Payment releases to the vendor (in Pro with vendor payouts configured) and the review window opens.

2. Request revision. The buyer identifies something that needs to change within the agreed scope. The order returns to In Progress 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 returns to In Progress with the vendor receiving 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
• In Pro with payout configuration active, the vendor’s earnings enter the hold period before becoming 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:

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

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 is paused 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 - approval of a refund, a partial refund, or confirmation of delivery. 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.