"A shop needs a website." That is the assumption, and it is wrong. You can run a real store — catalogue, orders, card, credits, and crypto checkout — where the only surface your customer ever sees is a Telegram channel, and the only surface you ever touch is an app on your phone. No storefront to design, no landing page to maintain, no cart to abandon. The channel is the catalogue; the checkout lives inside a conversation.

Diagram of a Telegram-native shop: CMS posts as catalogue, bot_telegram taking orders, token_payment and crypto settling the invoice, iOS SDK as the merchant console.

The storefront is a channel, not a page

Here is the constellation. The cms plugin holds your product content — each item is a post, with copy, images, and price. You publish those posts into a Telegram channel through bot_telegram, so the feed your customers already scroll is your shelf. When a customer taps to buy, the bot opens a conversation: it confirms the item, quantity, and address, and hands the order to the shop plugin, which owns products, variants, stock, and orders exactly as it would behind any web checkout. The difference is only the surface. The order object, the stock decrement, the invoice — all identical to a browser sale.

What makes this more than a novelty is where the money settles. Every VBWD plugin declares its charges as line items against one shared invoice interface. So the shop line item, any add-on, any fee — they all land on the same invoice regardless of how the order arrived. The bot does not need its own private billing logic. It writes to the same point of truth the web checkout would.

Three ways to pay, one invoice

Inside the chat, the customer can pay three ways, and you decide which you offer:

Because the payment core is provider-agnostic, adding another gateway later is roughly 100× less code than wiring one into a classic platform. You are not committing to a processor on day one; you are committing to an invoice, and the processor is a detail behind it.

You run the whole thing from your phone

The merchant side is the quiet surprise. VBWD is one Python backend that also ships a native iOS SDK — same core, native app. So the operator's console is not a web dashboard on a laptop; it is an iOS app. New order pushes in, you see it, you confirm stock, you mark it fulfilled, you watch the invoice settle. A one-person operation can run the entire business — publish a product to the channel, take the order in chat, get paid to their own wallet, fulfil — without ever opening a browser. The customer lives in Telegram; the merchant lives in an app; the backend quietly reconciles both against one invoice.

The event-driven core is what keeps those two surfaces honest. When an order is paid, the core emits an event; the bot can confirm to the customer, the iOS app can update, and any downstream automation you add — a shipping label, a thank-you message — hangs off the same signed webhook. You are not polling for state or stitching two systems together. One event fans out.

Why this combination is non-trivial

Plenty of tools let you post products to Telegram. What they do not give you is a checkout that is a first-class part of the same commerce backend as everything else — same stock ledger, same invoice, same event bus, same payment core with non-custodial crypto — reachable from a bot, a web page, or a native app interchangeably. The conversation is not a bolt-on funnel that dumps the customer back onto a website to actually pay. The conversation is the checkout. That is the piece people assume they cannot have without building a bespoke bot backend, and it is the piece that comes switched on.

It also composes. Want to run a flash promo in the channel? The discount plugin declares its line item against the same invoice. Want a referral loop so subscribers bring subscribers? That plugin plugs into the same core. None of it requires a restart — plugins toggle on and off live — so you can turn the crypto option on for a weekend campaign and off again without downtime.

The honest boundary

VBWD is a substrate, not a business. It gives you the catalogue-as-channel mechanics, the bot plumbing, the shared invoice, the multi-rail payment core, and the native app — but it does not give you the product, the photography, the pricing strategy, the customer trust, or the fulfilment. You still self-host it, and self-hosting means you own the uptime, the backups, the moderation of your channel, and the tax and compliance obligations of taking money. A bot cannot pack a box. What VBWD removes is the six months of plumbing between "I have something to sell" and "money is in my wallet"; what it cannot remove is the work of actually running the shop.

If you want to see the moving parts, the public SDK is at github.com/VBWD-platform/vbwd-sdk-public, the plugin and API documentation lives at vbwd.cc/docs, and you can reach the team at vbwd.cc/contact. The tarot app, the dice-market game, and the pharmacy shop already run on this same core — proof the substrate bends to real verticals, not just demos. A Telegram-only shop is one more shape it takes.

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.