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. The listings and the search are the fun part; the payouts and the commission ledger are where the eighteen-month projects go to die. On VBWD, those unglamorous parts are the switch-on parts. Vendor onboarding, listings, commissions, payouts, vendor subscription tiers, and promotions come as plugins you compose — you build the taste and the demand, not the reconciliation engine.

A functioning multi-vendor marketplace is not one feature; it is a stack of them. Here is how the constellation lines up:
None of these is a mock. Each declares its charges as line items against one shared invoice interface, which is the quiet architectural decision that makes the whole thing reconcile.
In a marketplace, a single 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, every time, across thousands of vendors, is the actual hard problem. VBWD's answer is that the point of truth is the invoice line item, and an event-based contract engine balances assets against obligations. 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 plugin here rather than an afterthought. Vendor payouts are downstream of a ledger that already knows, per order, exactly 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. This is the difference between a marketplace that reconciles by design and one where finance spends every month-end chasing a discrepancy.
It is worth being blunt about why this is the part that sinks projects. A commission-and-payout engine is boring to demo and brutal to get right: partial refunds, chargebacks after a payout has already gone out, multi-item orders split across vendors, currency rounding, and the audit trail a regulator will eventually ask for. Building that yourself is months of careful, unglamorous work that no investor ever sees. Composing it from withdraw and the shared invoice means those months are spent instead on the two things that actually determine whether your marketplace lives — supply and demand.
The subtle bit of a marketplace is that a vendor is simultaneously someone you pay and someone you bill. VBWD handles both directions on the same core. Through subscription, a vendor is on a tarif plan — you charge them recurringly for their tier, with add-ons and checkout already built. 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 flows are line items the core understands. Layer discount on top for launch promos or category-wide sales, and you have the full commercial surface of a marketplace without writing a billing system twice.
Because every plugin can 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 pay through the same provider-agnostic payment core the rest of the platform uses, so you localize to your market's rails — Stripe and PayPal, or regional providers where they matter — and you can settle in non-custodial crypto where funds move to the merchant's own wallet. Adding a gateway is roughly 100× less code than wiring one into a classic platform, so as your marketplace crosses borders you add rails instead of rebuilding checkout. The RBAC and multi-tenant core keeps each vendor's data and permissions scoped, and the GDPR-first posture matters the moment you hold personal data for both buyers and sellers.
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 have to solve the cold-start problem: recruit the first vendors, attract the first buyers, and keep both sides believing the other will show up. You own vendor vetting and fraud, dispute resolution, the trust and safety model, and the regulatory weight of moving other people's money — self-hosting a payout engine means you are responsible for KYC, tax reporting, and the correctness of every disbursement. VBWD removes the year of plumbing. It does not remove the market-making, the moderation, or the compliance, and it will not conjure a two-sided market that does not yet want to exist.
The public SDK is at github.com/VBWD-platform/vbwd-sdk-public, the plugin architecture and API map are documented at vbwd.cc/docs, and you can reach the team at vbwd.cc/contact. The reason to look is simple: the parts of a marketplace you were dreading are the parts that are already built.
VBWD is source-available under BSL 1.1 — free for commercial use while annual VBWD-attributable sales stay under the value of 6.7 BTC per year.