Payments are the one part of a SaaS you cannot afford to rent from a single landlord. Yet most stacks are built the other way around: the checkout, the subscription logic, the invoice math, and even the customer relationship are wired directly to one processor's SDK. Switch that processor and you are not swapping a library, you are rewriting your business. VBWD is built on the opposite premise. The payment provider is a detail your product should never have to know about, and the money should settle where you actually want it: your own account, or in the non-custodial case, your own wallet.
VBWD ships integrations for a deliberately wide set of payment providers: Stripe and PayPal for the global default, plus regional rails that matter enormously if your customers are not in San Francisco — PromptPay and TrueMoney in Thailand, Mercado Pago across Latin America, Conekta in Mexico, Toss in South Korea, and YooKassa for the Russian-speaking market. The reason this list is long is not vanity. Conversion at the payment step is dominated by whether the customer sees a method they already trust. A Korean buyer who cannot pay with Toss, or a Thai buyer without PromptPay, is a lost sale no amount of funnel optimisation recovers.
The important architectural point is what sits above those integrations. In VBWD the checkout, cart, subscription plans, discounts, and invoicing do not talk to Stripe or Toss directly. They talk to a provider-agnostic layer, and each processor is an adapter behind it. Adding a market means adding an adapter, not touching the flow your customers walk through. Removing a processor — because its fees rose, its policy changed, or it froze an account — means retiring an adapter, not a migration project. Your differentiated logic stays put while the rails underneath it are swappable.
For crypto and stablecoin payments VBWD does something most platforms quietly avoid: settlement is non-custodial. Funds move directly to the merchant's own wallet. VBWD is not an intermediary that takes your money, holds it, and pays out later on its own schedule and under its own terms. There is no float sitting in someone else's account, no platform-level freeze that strands your revenue, no counterparty whose insolvency becomes your problem. The architecture treats crypto settlement the way self-hosting treats everything else — you own the endpoint, so you own the outcome.
This is also provider-agnostic in the same sense as the card rails. Crypto and stablecoin support is one more settlement path behind the same checkout, not a bolt-on with its own parallel universe of billing code. The customer picks a method; your product does not branch.
Owning the rails is not only about money coming in. VBWD includes a withdraw capability for payouts — the outbound side you need the moment your platform has vendors, sellers, or affiliates to pay. Combined with the marketplace plugin for multi-vendor operations and referral for partner economics, the flow of money in both directions lives inside the same substrate rather than being stitched together from three unrelated SaaS bills.
For usage-based products there is token_payment, a token and credit economy for metered billing. Instead of forcing every product into a fixed monthly tier, you can meter what customers actually consume — API calls, generations, transactions, seat-hours — against a credit balance they top up. This pairs naturally with the subscription plugin (tarif plans, add-ons, and checkout) so you can run pure subscriptions, pure metering, or the hybrid that most real products converge on: a base plan plus metered overage.
When your subscription state, invoice history, dunning logic, and customer records live inside a single processor's dashboard, that processor owns your continuity. If they deplatform you, change terms, or have an outage, your ability to bill — and to prove what you billed — goes with them. VBWD keeps that relationship on your side of the line. Plans, invoices, discounts, referrals, and the ledger sit in your self-hosted core; the processor is just the last-mile transport for a given transaction. Because capabilities in VBWD toggle on and off without a restart and plugins live in their own space without forking the core, you can add a new regional provider, turn on metered billing, or enable crypto settlement as your business reaches those markets — incrementally, in production, without a re-platforming.
Owning the rails means owning the responsibilities that come with them. VBWD gives you a provider-agnostic, non-custodial architecture; it does not make you compliant. KYC/AML obligations, chargeback handling, tax treatment, and licensing are yours, and they are jurisdiction-dependent. Accepting crypto to your own wallet in particular carries reporting and regulatory duties that vary sharply by country and change over time. Nothing here is payment, legal, tax, or financial advice — it is a description of how the software is structured. You still choose your processors, sign their agreements, meet their and your regulators' requirements, and run the operations of self-hosting. VBWD is a substrate that removes the lock-in and the custody risk from your money movement; it does not remove your duty to run it responsibly.
That trade — you take on the operational and compliance ownership, and in exchange nobody else owns your billing relationship or holds your funds — is the whole point. It is the same bargain self-hosting always offers, applied to the most sensitive part of the stack.
If you want to see how the provider-agnostic payment layer and the plugin system fit together, the public SDK is open to read: github.com/VBWD-platform/vbwd-sdk-public. If you are weighing a migration off a single processor or planning multi-region and non-custodial settlement, get in touch.
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.