A quick heads-up on something we've been building: a native cryptocurrency payment method, headed for the VBWD SDK as one of the default ways to get paid. Not a bolt-on, not a third-party redirect — a first-class payment option that sits next to cards in the same admin, works for both single stores and multi-vendor marketplaces, and — the part that matters most — never puts a middleman between you and your money.
The module lets a merchant accept Bitcoin, Ether, and major stablecoins on-chain, and it is non-custodial by design. Instead of a processor receiving the coins and paying you out later (minus a cut), VBWD derives a unique receiving address for each invoice from your own watch-only key. The payment settles straight to a wallet only you control. The platform can watch the chain for the deposit, but it has no private key and cannot touch the funds. If you know BTCPay Server, it's the same self-custody philosophy — wired into VBWD's billing and invoice engine so a crypto payment behaves like any other payment on the platform.
The flow is careful where it needs to be: a per-invoice address (never reused), a locked fiat-to-crypto rate with a countdown so nobody is burned by a price swing mid-payment, and capture that is withheld until the deposit clears the confirmation threshold. When it does, the invoice is marked paid through the exact same internal path a card payment uses — so to the rest of your product, a Bitcoin order is just a paid order.
VBWD runs as a single-merchant store and as a two-sided marketplace, and the crypto module is built for both. For a single store, it's simply another payment method you switch on. For a marketplace, the same primitives slot into the vendor model, so on-chain payments attribute per vendor inside the platform's existing invoicing and payout machinery. Same code, both configurations — which is the point of building it as a proper part of the plugin catalogue rather than a special case.
Under the hood it follows the same pattern as every other payment method: the chain watcher and the exchange-rate source sit behind swappable interfaces. In testing it runs against deterministic mock adapters — no secrets, no live network — so the whole flow is verifiable in CI. In production you point those interfaces at a real node and a real rate feed. It's the same provider-agnostic architecture that lets VBWD swap card processors like Stripe, PayPal, and YooKassa without touching checkout — now extended to crypto.
The plan is to ship it as part of the standard set of payment methods bundled with the VBWD SDK, so operators can enable it from the admin rather than integrating a separate service. The capability has already been demonstrated end to end against test adapters; production support for live chains and rate feeds is what follows. We're not putting a hard date on it yet — but consider this the spoiler.
Accepting crypto has usually forced a bad choice: hand your payments to a custodian who holds the coins and takes a cut, or wire up a node and a mountain of edge cases yourself. A default, non-custodial method changes that calculus. A self-hosted store or marketplace gets to accept Bitcoin the way it accepts anything else — a toggle in the admin — while the coins go straight to the owner's wallet. Ownership of your stack, extended to ownership of your payments.
Want the technical detail? There's a full screenshot-by-screenshot walkthrough of the money loop — per-invoice addresses, rate locks, threshold-gated capture, and the idempotent webhook — on the blog. This is just the heads-up that it's coming to the SDK.