Everyone underestimates the same three things when they set out to build a marketplace: paying the vendors, reconciling the money, and billing the vendors themselves. Listings and search are the fun part; payouts and the commission ledger are where 18-month projects go to die. The counterintuitive claim is that those unglamorous parts can be the switch-on parts — vendor onboarding, listings, commissions, payouts, vendor tiers, and promotions composed from plugins, so you build the taste and the demand instead of the reconciliation engine.

A marketplace mapped to plugins

The idea comes from an analysis on VBWD, a self-hosted, source-available full-stack SaaS SDK. A functioning multi-vendor marketplace is a stack: the marketplace plugin holds vendors and their storefronts, shop holds products and stock, cms is the content and SEO skin, subscription charges vendors for their tier, withdraw pays vendors out, and discount runs promotions — all collecting through the provider-agnostic payment core. None of it is a mock; each plugin declares its charges against one shared invoice, which is the quiet decision that makes the whole thing reconcile.

The invoice is the reconciliation engine

A single marketplace order can involve four money movements: the buyer pays, the platform keeps a commission, the vendor is owed the rest, and a discount reduces the total. Getting that arithmetic right across thousands of vendors is the actual hard problem. As the original analysis puts it:

The buyer’s payment, the commission the platform earns, the discount that was applied, and the payout owed to the vendor are not four systems you glue together and pray they agree. They are entries against one invoice, on one balance.

That is why withdraw is the headline here rather than an afterthought. Vendor payouts sit downstream of a ledger that already knows, per order, what each vendor is owed net of commission and refunds:

The payout is not a fresh calculation you hope matches your books — it reads from the books.

It is worth being blunt about why this sinks projects. A commission-and-payout engine is boring to demo and brutal to get right: partial refunds, chargebacks after a payout has gone out, multi-item orders split across vendors, currency rounding, and the audit trail a regulator eventually asks for. Composing it means those months go to supply and demand instead.

Vendors as customers and sellers at once

The subtle bit is that a vendor is simultaneously someone you pay and someone you bill. Through subscription a vendor is on a recurring tarif plan for their tier; through withdraw that same vendor receives their sales proceeds. Money flows to them for what they sold and from them for the privilege of selling, and both are line items the core understands. Because plugins toggle on and off without a restart, you can launch lean — listings and buyer checkout only — and switch on vendor subscriptions or promotions later, live, once you have supply worth charging for. Buyers settle through the same payment core, including non-custodial crypto to a merchant wallet, so crossing borders means adding rails rather than rebuilding checkout.

The honest boundary

Switching on a payouts and commission engine is not the same as running a marketplace. VBWD gives you the ledger, the vendor billing, the payout mechanics, and the settlement rails — it does not give you liquidity. You still solve the cold-start problem, own vendor vetting and fraud, run dispute resolution, and carry the regulatory weight of moving other people’s money: KYC, tax reporting, and the correctness of every disbursement. The platform removes the year of plumbing; it will not conjure a two-sided market that does not yet want to exist.

The parts of a marketplace you were dreading are the parts that are already built — read the full analysis on VBWD, and the public code is on GitHub.

Written for Red Robot with AI assistance and human editing. Adapted from an original analysis published on VBWD.