Most software companies treat partners as a marketing footnote: a logo wall, a coupon code, a quarterly spreadsheet reconciled by hand. That works until you have real volume, and then it collapses into disputes about who referred whom, commission paid on refunded orders, and a payout process that lives in someone's inbox. If you run an agency or resell a white-label product, you have felt this from the other side too: you drove the sale, and getting paid for it is slow, opaque, and manual.
VBWD ships a referral and payout rail as part of the platform, not as a bolt-on. It is built the same way the rest of VBWD is built: an agnostic core, plugins that extend behavior through the event bus and registries, and a provider-agnostic port at the boundary where money leaves the system. This article covers what the rail is, how partners get attributed, how commission moves through its lifecycle, how payouts stay provider-neutral, and the business shape it creates — plus the parts that are your responsibility, not the software's.
The rail is a Stripe-Connect-style system. That phrasing is deliberate: it behaves like a connected-accounts platform, but it is not welded to Stripe. Partners onboard as connected accounts on a VBWD hub instance. Sales attributed to those partners accrue commission. When commission is confirmed, payouts are pushed out through a provider-agnostic IConnectProvider port. Stripe is the first implementation behind that port; another processor can be added by writing a new adapter, without touching the attribution or lifecycle logic that sits above it.
This matters because the two hard problems in a partner program are separable. One problem is attribution and accounting — knowing which sale belongs to which partner, how much commission it earns, and whether that commission is still owed after refunds. The other problem is moving money — KYC, onboarding, and the actual transfer. VBWD keeps the first problem in its own domain, where it is deterministic and testable, and pushes the second problem behind a port so you can choose your processor. The rail is one of the plugins in the VBWD plugin catalog, extending core through the same event bus every other plugin uses, so enabling it does not fork your platform.
Onboarding a partner is two steps that map cleanly onto the two problems above. First, the partner is registered on the hub as a connected account and taken through the payment provider's onboarding flow — the KYC and account-verification steps that the provider requires before it will send money anywhere. Second, the partner is issued an attribution handle: the identifier that links a downstream sale back to them.
Attribution is where partner programs usually leak. VBWD attaches the partner identifier to the sale at the point the order is created, so the link is recorded in the same transaction as the purchase rather than reconstructed later from logs. When a referred customer buys, the resulting invoice carries the attribution, and a commission record is created off the back of the order event on the event bus. Because the attribution lives on the order itself, a refund or a plan change later can find the exact commission it needs to adjust. If you want the mechanics of how order and invoice events fan out to plugins, the platform architecture overview describes the event-bus and registry seams the rail is built on.
Two practical notes for agencies and OEM partners:
A commission record is not a single number that gets marked "paid." It moves through explicit states, and the transitions are idempotent — the same event arriving twice does not double a commission or pay it twice. The states are:
pending ──confirm──▶ confirmed ──payout──▶ paid
│ │
└──reverse──▶ reversed ◀──reverse──┘
The idempotency is the part that saves you at scale. Payment providers retry webhooks. Order pipelines replay events after a deploy. Without idempotent transitions, every retry is a risk of a duplicate payout. VBWD keys transitions on the commission and the triggering event, so replays are safe and the ledger stays honest. The reversed state is the one that separates a real payout system from a spreadsheet: chargebacks and refunds are normal, and a partner program that cannot claw back commission on returned money will slowly bleed margin.
When confirmed commissions are ready to be sent, they go out through the IConnectProvider port. The port defines the operations the platform needs — onboard a connected account, check its payout readiness, push a transfer — and each processor is an adapter that implements them. Stripe Connect is the first adapter because it is the most common answer for platforms that need to pay third parties, but the platform code above the port does not know or care that it is Stripe.
The reason to build it this way is not abstraction for its own sake. Payment providers differ by geography, by supported partner countries, by fee structure, and by what they will and will not underwrite. A partner base that spans regions may need more than one processor. A change in provider terms should be an adapter swap, not a rewrite of your commission engine. Keeping the money-movement concern behind a single port is the same discipline VBWD applies to payment providers on the buying side — the SDK adapter pattern shows up again here on the payout side.
The referral and connect rail is designed to run on a hub instance, and it is meant to coexist with entitlement licensing on that same hub. That coexistence is the business shape worth understanding, because it gives you two revenue rails on one piece of infrastructure:
Running both on one hub means the sale that triggers a license entitlement is the same sale that accrues a partner commission, off the same order event. You are not stitching a licensing system to a separate affiliate tool through a nightly export. For an OEM or white-label partner, this is the difference between "we'll reconcile at quarter end" and a commission record that exists the moment the license is sold. If you are evaluating how the licensing side is packaged, the pricing and licensing page lays out the entitlement model that the connect rail sits alongside, and the billing and invoicing overview covers the invoice events the commission records are derived from.
This is the part that partner-program marketing usually omits, so read it carefully. VBWD provides the mechanism — attribution, the commission lifecycle, and the payout port. It does not provide the legal and compliance layer, and running payouts means taking on real obligations:
None of this is a reason to avoid running a partner program — it is the normal cost of paying people, and the rail is built to handle the mechanical part of it well. But treat the software as the accounting and payout engine, not as a substitute for a payments lawyer and an accountant. VBWD itself is self-hosted and source-available under BSL 1.1 — free until attributable annual sales reach the equivalent of 6.7 BTC, converting to Apache-2.0 after the change date — so you run this rail on your own infrastructure, with your own provider accounts, under your own compliance posture.
A partner program is only as good as its ledger. VBWD's referral and connect rail gives you server-side attribution recorded on the order, an idempotent commission lifecycle that handles refunds and chargebacks through an explicit reversed state, and a provider-agnostic payout port so your processor is a choice rather than a lock-in. Because it runs on the same hub as entitlement licensing, one order event can both grant a license and accrue a commission — two revenue rails on one platform, built on the same agnostic-core, event-bus foundation as everything else VBWD ships. The software owns attribution, lifecycle, and payout mechanics. You own the rates, the compliance, and the tax reporting. Understand that split and the rail does exactly what a partner program needs: it pays the right people the right amount, and it stops paying them when the money comes back.
Want the implementation detail? See the VBWD documentation for the connect provider port, the commission state machine, and how to enable the rail on a hub instance.