Milestone payments in WP Sell Services work like this: a custom project is split into phases, the buyer pays each phase up front, and the vendor’s wallet is credited the moment that payment clears. Approving a delivery doesn’t move any money. The plugin doesn’t hold funds and release them later.
If you came here looking for a marketplace plugin that holds the buyer’s money until the work is approved, that’s not what this does, and it’s better to say so now than after you’ve built your terms of service around it. What it gives you is pay-as-you-go: small, sequential payments that cap how much either side has at risk at any one time.
This post explains how a phase moves, who carries the risk at each step, and when you’d skip milestones and sell a single fixed-price order instead.
Pay-per-phase is not the same as holding funds
People use the two ideas interchangeably, and they’re different. In a model where funds are held, the buyer pays the whole amount at the start, the platform keeps it, and the vendor receives it when the buyer approves. Money moves on approval.
In a pay-per-phase model, the buyer pays only for the phase in front of them. That payment goes through at once and the vendor is credited, minus your commission. When the buyer later approves the delivery, that’s a record that the phase is done. Nothing is released, because nothing was held.
Why does it matter? Because the guarantee each side gets is different. A buyer on a held-funds platform has paid in full and is relying on the platform to hand the money back if things go wrong. A buyer on pay-per-phase has paid for one phase and is relying on a vendor who’s already been credited for it. The exposure is smaller per step, but it isn’t zero.
How a phase moves from proposal to done
Milestones live on orders that start from a buyer request: the buyer posts a brief, vendors reply with proposals, and a vendor can choose a Milestone contract type. They list each phase with a title, a description, an amount and a number of days. The buyer sees the whole plan before accepting, and the order starts with a base price of zero. All of the money flows through the phases.
From there each phase follows the same loop:
- The buyer pays the phase.
- The vendor is credited and the phase moves to In progress.
- The vendor does the work and submits a delivery.
- The buyer approves it, or sends it back with notes.
Phases run in lock-step. Phase two can’t be paid until phase one has finished, which means approved, declined or cancelled. Paying a phase doesn’t unlock the next one. Approving it does. That keeps the project in rhythm and stops a buyer stacking up prepayments for work they haven’t seen.
Vendors can propose extra phases once the project is running, and those have a clock on them. An added phase the buyer hasn’t paid within 48 hours is cancelled automatically. Phases from the original accepted proposal never expire this way. The milestones documentation has every state and error in full.
Who carries the risk at each step
Think about it one phase at a time and it gets clearer.
The buyer has paid for the current phase and hasn’t received it yet. That’s the part to be upfront about with your customers. If the vendor disappears, the buyer’s recourse is a dispute, not an automatic refund.
The vendor is credited at payment, so they know the money exists before they start. They aren’t working on trust, which is the main reason good vendors like this model. They also can’t start the next phase until the current one is settled, so they’re never far ahead of what they’ve been paid.
You, the marketplace owner, carry a smaller risk than you might expect but a real one. The vendor’s earnings are in their wallet from payment, so if a refund lands after you’ve paid the vendor out, the reversal becomes a debt that nets against their future earnings. You can soften that with a clearance period in the payout settings, which holds credited earnings (milestone phases included) for a number of days before they can be withdrawn. How long to hold is your call. The plugin doesn’t impose one.
Disputes and refunds
Once a phase is paid, the buyer can’t simply decline it. A paid phase can only be settled through a dispute. Either side opens one, both sides add their evidence, and an admin picks a resolution, which can be a full or partial refund. Read how that works in the dispute process docs.
This is the honest centre of the whole feature. Your admins are the referee. If you’re going to run a marketplace on this model, decide in advance how quickly you’ll respond to disputes and what evidence you’ll expect, and write it into your terms. A buyer who’s paid for phase two and isn’t getting a reply from the vendor wants to know a person is on the other end of the dispute button.
Declined and unpaid phases are simpler. A vendor can cancel a proposed phase the buyer hasn’t paid, and a buyer can decline one. No money has moved, so there’s nothing to reverse.
When a single fixed-price order is better
Milestones are for scoped projects where neither side wants to commit the full amount on day one: a website build, an edited manuscript, a phased consulting engagement. They aren’t the right fit for a one-off logo or a thirty-minute consultation, and they don’t exist on catalog orders at all. For a fixed-price service, extra paid work goes through extensions instead, and the two features never appear on the same order.
If a buyer wants the money protected until the very end of the project, pay-per-phase can’t offer it. Be clear about that in your marketplace’s copy, and don’t borrow language from platforms that work differently.
Setting it up
Milestones are part of the free plugin and sit on the buyer-request flow, so the first step is having that flow in use and a vendor ready to reply with a proposal. Phase payments run on the standalone checkout, WooCommerce or FluentCart. On Easy Digital Downloads neither milestones nor paid extensions are available.
Then decide three things before you launch. Set your commission rate and any clearance days in Settings. Write down your dispute response time. And tell vendors in your onboarding that approving a phase confirms delivery and doesn’t release anything, so they don’t wait for a payout that already happened at payment.
If you want the wider picture first, custom WooCommerce flows a service marketplace needs covers milestones alongside the other flows that standard checkout doesn’t. The request marketplace use case shows the buyer-request model end to end, and free vs Pro lists what each tier includes.