Every existing way to run a service marketplace on WordPress made you pick a compromise.
You could stack WooCommerce with 4-5 marketplace plugins: Dokan or WCFM as the multi-vendor layer, a custom-fields plugin for the requirements form, a chat plugin for buyer-vendor messaging, a withdrawals plugin for payouts, a custom CSS pack to hide the parts of WooCommerce that don’t apply to services. It worked, sort of. Until any of those plugins updated and broke the chain.
You could rent a SaaS marketplace: Sharetribe, Arcadier, ListingHub. Pay a monthly fee for the privilege of building your business on someone else’s roadmap. Branding limits, data lock-in, no control over the commission engine.
You could commission custom development: six months of agency time and twenty thousand dollars to build what already exists in fragments across other plugins.
Or you could wait for the right tool.
The gap in the WordPress ecosystem
Dokan, WCFM, and WC Vendors are excellent. For physical-product marketplaces. They were designed when “marketplace” meant Etsy clones and multi-vendor stores selling t-shirts. The data model is product, the order state machine ends at completed, and the workflows assume inventory + shipping.
Services don’t have inventory. Services have requirements that need to be collected before work starts. Services get delivered as files, not packages. Services often need revisions. Services sometimes fail and need a dispute system that knows what “fail” means in the context of a 2-week consulting engagement.
Retrofitting product plugins to fit services is the job that consumes thousands of hours across the WordPress community every year. Every freelance marketplace owner ends up reinventing the same patches.
What we decided to build
WP Sell Services was designed from day one for service workflows. The decisions that flow from that:
Requirements collection is a first-class part of the order. When a buyer purchases a service, the order waits for the buyer to fill the vendor’s intake form, with reminders on days one, three and five. That form is built into the service listing. Vendors define their questions once, and every buyer answers before work starts, unless you choose to let an order start without the form after a timeout you set.
The order state machine matches reality. Orders go: pending payment → waiting for requirements → in progress → delivered, pending approval → revision requested → completed. Each state has a different UI on the vendor and buyer dashboard, different notification emails, different available actions. This is how service work actually flows.
Delivery is its own event. Vendors upload deliverable files attached to the order. Each delivery has a timestamp, a file batch, and a note. Buyers see all deliveries in chronological order. The order doesn’t complete on payment. It completes when the buyer accepts, or automatically if the buyer neither accepts nor asks for a revision within a window you set, which ships at three days.
Disputes resolve with full context. When something goes wrong, the dispute screen shows both sides’ statements and evidence, the buyer’s requirements and every delivery, and links to the order’s timeline and message thread. Admin (you) has what is needed to resolve fairly. No guessing.
Two marketplace modes, both built in. Buyers can browse a catalog and buy a fixed-price package (Fiverr-style) OR post a brief and receive proposals (Upwork-style). Most marketplaces force you to pick one. We ship both because real demand has both shapes.
Five problems a service marketplace has that a product store doesn’t
A product store sells a thing that exists. A service marketplace sells a promise, and most of the software has to manage the distance between the promise and the result. These are the five places that distance shows up, and how the plugin answers each.
Requirements: the work can’t start without the brief
A product ships from a shelf. A service ships from the buyer’s answers. Without them, the vendor guesses, and guesses become revisions.
The plugin makes the brief part of the order. Each listing carries its own questions, in eight answer types from short text to file upload. After payment the order sits in Waiting for Requirements, the delivery clock does not run, and the buyer gets reminders by notification and email. A requirements timeout, seven days by default, decides whether a silent buyer’s order starts anyway or is cancelled. The longer walk-through is in collecting requirements before work starts.
Delivery: the product is a file, a message or a result
There is no parcel to track. A delivery is a set of files and a note, and the buyer needs to be able to find it, download it and compare it with earlier versions.
Each delivery is recorded with its files, its note and its time, and every version is kept. Files are stored outside the public web root and served through a link that checks who is asking, so only the buyer, the vendor and an administrator can fetch one. Cloud storage, a Pro feature, serves short-lived signed links instead. Uploads are limited to an allowed-types list you control in the Advanced settings, and SVG is left off it by default because it can carry scripts.
Revisions: a product return is a refund, a service return is a conversation
Buyers rarely want their money back for a logo that is nearly right. They want it changed. Without a model for that, every disagreement becomes a refund request.
Each package sets how many revisions it includes, from none to unlimited. When the buyer asks for one, the open delivery is retired, the vendor sees the buyer’s notes, and the revision gets a fresh deadline counted from the request, so it isn’t late before it starts. When revisions run out, the buyer can accept the work, negotiate an extra paid revision or open a dispute.
Disputes: nobody can see what was promised
When a product arrives broken, the evidence is a photo. When a service disappoints, the evidence is a brief, a thread and a series of files, and someone must read all of it.
A dispute can be opened by the buyer or the vendor while an order is in progress, late, on hold, in revision or awaiting approval, and after completion for as long as the dispute window lasts. Each order can have one. The admin rules in one of five ways: full refund, partial refund, in favour of the vendor, in favour of the buyer, or a mutual agreement. Rulings in the vendor’s favour or by agreement complete the order, and the refund outcomes move it to refunded or partially refunded. A separate setting can open a dispute for the buyer when an order has been late for too long.
Payouts: someone is owed money later
A product store keeps the revenue. A marketplace owes most of it to someone else, after a delay, minus a cut, with refunds possible in between.
The plugin keeps a ledger as the single record of what vendors have earned and been paid. Commission is worked out and fixed when the order is paid, so a later rate change doesn’t rewrite it. Earnings are credited when an order completes, or for a milestone phase when the buyer approves it. A clearance period you choose holds credits before they can be withdrawn, and it ships at zero. Vendors request withdrawals, one at a time, and you approve and pay them. The details are in how vendor payouts work.
Trust has to be earned inside the marketplace
A fifth problem sits underneath the other five: a new marketplace has no reputation, so buyers can’t tell good sellers from bad ones. Product stores borrow trust from brands. A services marketplace has to manufacture it.
Two features carry that load. Reviews can only come from the buyer of a completed order, once, within a review window that ships at thirty days, and the vendor can reply. Seller levels are worked out from real orders, ratings, reviews and on-time delivery rather than handed out, and an admin can still grant a level by hand for sellers you have vetted. The thresholds are set out in seller levels earned from real orders.
Constraints we held ourselves to
Some decisions were about what not to do, because each shortcut would have created a problem later.
- One source of truth for money. Balances come from the ledger, not from sums in several places that could disagree.
- The licence never decides who a user is. Pro adds features. It adds no roles and no capabilities, so a lapsed licence can’t strip abilities from real people.
- One checkout owns payment. When an ecommerce platform is active, it handles payment completely, and the plugin does not run a second checkout beside it.
- Member data stays reachable. A member can export their data and request erasure through the standard WordPress privacy tools, and deletion is refused while an order is in flight or a payout is mid-transfer, so nobody can leave owing work or money.
- The plugin is meant to be extended. There is a REST API, documented hooks and filters, WP-CLI commands, template overrides, blocks and shortcodes, so that customising doesn’t mean forking.
What the plugin deliberately does not do
Honesty about limits is part of the reasoning. These are things people sometimes assume are included.
- It does not hold the buyer’s money in a third-party escrow. Payment goes through your gateway, and the ledger decides when the vendor can withdraw.
- It does not offer recurring billing for services. That is not available.
- It does not collect vendor tax forms or produce year-end tax documents.
- It does not integrate wallet plugins as payout choices. Vendors are paid from its own balance.
- It does not treat Easy Digital Downloads or FluentCart as production checkouts. Both are in beta and off by default.
If one of these decides your build, better to know before you start. The free versus Pro page keeps the full list current.
Who it is for, and who it isn’t
The plugin suits a site owner who wants a services marketplace on their own WordPress install, with their own branding, commission and data. It suits someone who would rather configure than build, and who is comfortable running the site themselves: hosting, updates and support are yours.
It suits less well someone who wants a hosted platform with a built-in audience, or who needs escrow, subscriptions or tax reporting out of the box. For those, a hosted service or custom development may be the honest answer. The site owner overview and the features page show what you would be working with, and the freelance marketplace use case walks through a complete build.
A practical way to test the fit is to install it on a staging copy and run one order of each kind yourself. Buy a catalog service as a test buyer, answer the requirements form, deliver as the vendor and request a revision. Then post a brief, send a milestone proposal, and open a dispute on a paid phase. Twenty minutes of that tells you more than any feature list, and the order lifecycle guide tells you what to expect at each step.
What we chose to leave for Pro
The free plugin is complete enough to run a production marketplace. The order workflow, reviews, disputes, commission and withdrawals are all free. Where free has ceilings, they sit on how rich a listing can be, such as the number of gallery images or add-ons, and Pro lifts them.
The Pro modules solve problems that show up after the marketplace works:
- WooCommerce checkout integration. When you outgrow Stripe + PayPal and need regional gateways without polluting the catalog with physical products.
- Vendor analytics. When vendors start asking you for data you don’t have.
- Stripe Connect and PayPal Payouts. When manual withdrawal review is a part-time job.
- Cloud storage. When delivery files exceed your host’s disk limits.
- White-label. When you want your marketplace’s brand instead of ours.
We sell Pro as a yearly licence, or a one-time lifetime licence. No SaaS. No per-vendor pricing. No commission on your transactions.
What we’re not
This isn’t a Fiverr competitor. We’re not building a hosted marketplace. We don’t see vendors. We don’t see orders. We don’t have access to your data. We’re a plugin. Installed on your server, owned by you.
We’re also not a marketplace toolkit for everything. If you’re selling physical products, WooCommerce + Dokan is still the right answer. If you’re running a multi-vendor digital products store, Easy Digital Downloads with the front-end submission addon fits better. WP Sell Services is the right tool when the product is a service.
What’s next
The documentation is at wpsellservices.com/docs/, and the free vs Pro page says plainly what Pro does not do yet.
If something missing would change your build decision, we want to hear it. Reach us via support.