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

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

1. Pending Payment
2. Waiting for Requirements
3. In Progress
4. Pending Approval (the delivered state, while the buyer reviews)
5. Revision Requested (optional loop back from Delivered)
6. 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 Pending Approval 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”. They can message the buyer, but they cannot deliver until the 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 accept or request a revision yet, because nothing has been delivered. The vendor can send the delivery or message the buyer, and either side can still ask to cancel or open a dispute.

State 4: Pending Approval (delivered)

The vendor submits a delivery by uploading files and writing a delivery note from their vendor dashboard. The order moves to 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 everyday actions in this state, plus a fourth for emergencies:

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 (three days unless you change it), the order completes automatically. This is a critical protection for vendors - a buyer who disappears after delivery cannot hold a completed order hostage indefinitely.

4. Open a dispute. For a serious problem that a revision will not fix. Disputes get their own section below.

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 Pending Approval, and the auto-complete countdown restarts from the new delivery. The revision also gets a fresh deadline, counted from the moment the buyer asked, so it is not marked late just because the original deadline passed while the buyer was reviewing.

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 by the buyer, once, after completion, and within the review window (30 days unless you change it). The vendor can reply to it. WP Sell Services does not allow reviews on in-flight orders. This prevents the pattern where a buyer uses a review as a bargaining chip and threatens a negative review during a dispute over revision scope.

The states that sit outside the main path

The six states above cover a smooth order. The others exist so that a problem has a name and an owner instead of living in someone’s inbox.

• Late. An hourly check marks an in-progress or revision order as Late once its deadline has passed, and notifies both sides. The vendor can still deliver from Late. About a day before the deadline of an in-progress order, the vendor also gets a reminder.
• On Hold. An admin pauses the order, for example during a fraud check. It resumes to In Progress or ends in cancellation.
• Cancellation Requested. One side asks to cancel and the order waits for the other to answer. If the vendor does not respond within 48 hours, the cancellation is approved automatically and both sides are told.
• Disputed. Covered at the end of this guide.

Lateness has a consequence beyond the label. The plugin can open a dispute on the buyer’s behalf when an order stays late for a set number of days. That setting ships at three days and can be turned off by setting it to zero.

An example timeline, with revision

These numbers are an example, using a five-day package and the default settings.

1. Day 0: the buyer pays. The order enters Waiting for Requirements.
2. Day 1: the buyer submits the form. The order is In Progress and the five-day deadline starts.
3. Day 6: the vendor delivers. The order is Pending Approval.
4. Day 7: the buyer asks for a revision. The vendor now has five fresh days.
5. Day 10: the vendor redelivers, and the three-day auto-complete countdown restarts from that delivery.
6. Day 11: the buyer accepts. The order is Completed, the commission is recorded and the vendor’s share is credited.

Nothing in that sequence needed an admin. That is the point of the state machine: the admin only appears when something leaves the path.

The settings that shape the lifecycle

Most of what you have read about timing is a setting under the orders and disputes tab. These are the defaults the plugin ships with.

What an admin checks each week

You do not need to watch every order. A short routine catches nearly everything.

• Open the orders list and filter by Late. A cluster of late orders from one vendor is a conversation to have.
• Filter by Waiting for Requirements and look for orders older than your reminder schedule.
• Check Cancellation Requested for requests close to the 48 hour mark.
• Work through open disputes before the auto-complete and dispute windows make the situation harder to unpick.

The order lifecycle documentation lists every status and the exact emails sent. If you are choosing settings for a new marketplace, the site owner overview and the features page show the controls in context.

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

Either party can open a dispute while the order is in progress, late, on hold, in revision or waiting for approval, and also after completion for as long as the dispute window lasts (14 days unless you change it). Each order can have only one dispute. When a dispute opens, the order moves to Disputed and admin receives a notification.

The dispute screen in the admin shows both sides’ statements and evidence, the order’s payment details, every delivery and the buyer’s requirements, with a link straight to the order’s timeline and message thread. 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. Resolving a dispute in the vendor’s favour or by mutual agreement completes the order; the refund outcomes move it to refunded or partially refunded.

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.