Launch a Two-Sided Marketplace with VBWD: Vendors, Checkout, and Payouts

Spread the love

Run a marketplace on VBWD: an agnostic vendor layer, a shared listing contract, buyer checkout, and Stripe-Connect-style commission payouts — self-hosted, with no platform cut for the operator.

A marketplace is a vendor layer, a checkout, and a payout rail; VBWD provides all three as plugins so you keep the commission and own the vendor relationships.

You already have the buyers. Now add the sellers.

Most marketplace projects die in the same place: not the product, but the tax the platform charges you to run one. You build an audience, sign up vendors, drive sales — and hand a percentage of every transaction to a hosted platform you don’t control. VBWD flips that arrangement. It’s a self-hosted, source-available platform where a two-sided marketplace is a plugin you switch on, not a SaaS bill you pay forever.

This piece walks through what that actually means: how vendors and listings work, how checkout splits money into commission and payout, what the economics look like next to a hosted marketplace, and where the honest limits are.

What a marketplace on VBWD actually is

VBWD is a plugin platform with a deliberately agnostic core. The core knows about users, catalogues, checkout, invoicing, and payments. It does not know what a “vendor” is. That’s the point.

The marketplace lives in a plugin that adds a “vendor mode” — an agnostic vendor layer that sits on top of whatever you’re already selling. Products, datasets, digital goods, services: they don’t have to be rewritten to become marketplace items. The coupling is intentionally thin. A product becomes a vendor’s product by carrying a bit of extra data (a vendor_id) rather than by the core growing a hard dependency on the marketplace. Turn the plugin off and your catalogue still works; the core never learned a vocabulary it shouldn’t own.

The stack underneath is boring on purpose, which is what you want for something handling money: Python/Flask and PostgreSQL on the backend, Redis for the fast paths, Vue 3 and TypeScript on the front end, all in Docker. You can read how the agnostic-core plugin model is put together on the architecture pages, and browse what ships as plugins on the plugins list.

Vendors and listings

A two-sided marketplace needs two motions: vendors onboard and list, buyers browse and buy. VBWD handles the vendor side through the vendor layer the marketplace plugin adds. Vendors get onboarded, and once they exist, the items they create are tagged to them through that extra-data coupling — no separate parallel product system to keep in sync.

Listings reuse machinery the platform already has instead of reinventing it. The catalogue and listing views run on the shared, agnostic filter-and-pagination contract that the rest of the platform uses. Concretely, that means:

A single wire contract for list responses — items, total, page, per-page, page count — so front-end filtering and pagination behave the same whether you’re listing products, datasets, or vendor items.
Filtering and faceting handled by a reusable seam rather than bespoke code per vertical.
Listing and landing pages built with the CMS, so your marketplace home, category pages, and vendor spotlights are content you edit — not templates you redeploy.

The practical payoff: a vendor’s storefront and your category pages aren’t a separate app. They’re the same catalogue and CMS you already operate, filtered by vendor.

Checkout, commission, and payouts

This is where a marketplace earns its name. A buyer checks out through the same checkout and invoicing engine the platform uses for any sale — line items, per-line tax handled by the billing engine, and payment taken through a swappable payment adapter. Payments aren’t welded to one processor; adapters are plugins, so the processor is a choice, not a rewrite.

The money split runs on a Stripe-Connect-style rail. VBWD models it behind a provider-agnostic port — think of it as an IConnectProvider interface with Stripe as the first implementation — so the payout mechanics aren’t hard-coded to a single vendor either. When a sale completes, the platform records a commission and moves the rest toward the vendor’s payout.

Commission isn’t a single number stamped once. It has a lifecycle, so your books reflect reality as orders mature:

pending  ->  confirmed  ->  paid
                 |
                 +-->  reversed   (refund / chargeback / cancelled)

pending — sale captured, commission accrued but not yet earned.
confirmed — order settled past your return/dispute window; commission is now real revenue.
reversed — a refund or chargeback unwinds it, instead of leaving a phantom line on your P&L.
paid — the vendor has been paid out their share.

The operator — you — earns the commission. And because VBWD’s licensing and payout systems share one hub, a single deployment can run two revenue rails at once: platform licensing on one side, connect-style marketplace payouts on the other. You’re not standing up two separate systems to monetize two different things. The moving parts are documented in the docs.

The economics vs a hosted marketplace

Here’s the part that changes the math. On a hosted marketplace platform, the platform takes a percentage of your gross merchandise volume, forever. That cut scales with your success — the better your marketplace does, the more you pay, and none of it comes back as equity or ownership.

VBWD is self-hosted. There is no platform transaction cut going to a middleman for the privilege of operating your own marketplace. You still pay your payment processor its fees — that’s unavoidable and it’s between you and them — but there’s no additional layer skimming a percentage off the top on the way to you.

The licensing terms are built for this. VBWD is source-available under BSL 1.1: free to run commercially until your VBWD-attributable sales cross a threshold denominated in Bitcoin (6.7 BTC per year, measured on the annual average), after which a commercial license applies. The license converts to Apache-2.0 over time. In plain terms, you can launch, grow a real marketplace, and owe nothing to the platform until it’s genuinely producing at scale — and even the paid tier is a license, not a permanent cut of every sale.

The ownership point matters as much as the fee point. Because it’s self-hosted, you own the data and you own the vendor relationships. Your vendor list, buyer history, and payout records live in your PostgreSQL database, not in an account you rent. If you ever want to migrate, restructure commissions, or add a vertical, nobody’s terms-of-service stands between you and your own operation. See the current terms on the pricing page.

The honest limits

Self-hosted means you hold the pager. That’s the trade for owning the economics, and it’s worth being clear about it before you commit.

You run the infrastructure. Uptime, backups, upgrades, monitoring — the things a hosted platform absorbs into its fee are now yours to operate. Docker makes the deployment tractable, but tractable is not zero.
Payout and KYC compliance are your responsibility. The marketplace and connect rails are part of the platform’s design, and Stripe-Connect-style onboarding handles a lot of the KYC mechanics — but the obligations to your payment service provider, and to your buyers and vendors, sit with you as the operator. Treat KYC, anti-fraud, and payout compliance as work you own, not a checkbox the software clears for you.
Tax and regulation follow your jurisdiction. The billing engine computes per-line tax, but configuring it correctly for where you and your vendors operate is a task, not a default.

None of these are reasons not to build. They’re the reasons the model is cheaper: you’re doing the operating work instead of paying someone a percentage of every sale to do it for you. For many operators — especially ones who already run infrastructure — that’s a straightforward trade.

Where to start

A marketplace on VBWD isn’t a product you buy; it’s a plugin you enable on a platform you control. The vendor layer keeps the core clean, checkout and payouts run on a provider-agnostic connect rail with a proper commission lifecycle, and the economics keep the transaction margin with you instead of a host. The cost is that you operate the thing and own the compliance — which is exactly why there’s no percentage leaving your books on every order.

If you have an audience and a reason to bring sellers to it, the pieces are already in the platform. Stand up the stack with Docker, switch on the marketplace plugin, wire your payment adapter, and start onboarding vendors. Everything you need to evaluate it is at vbwd.cc — the architecture is open, the source is available, and the only percentage in the deal is the commission you set for yourself.