Billing is where a lot of promising products quietly break. The demo works, the first customer pays, and then reality arrives: a customer in another currency, a plan change mid-cycle, a metered feature that needs credit rather than a flat fee, a tax authority that wants a per-rate breakdown, a refund that has to reconcile against an invoice. VBWD treats all of that as solved infrastructure rather than something you assemble yourself. This is a tour of the billing engine — plans, multi-currency, the token/credit system, and the invoice lifecycle — and how they fit together.
Everything commercial starts with a tariff plan. A plan defines what a customer is buying: a name, a price, a currency, a billing period, and the limits or entitlements that distinguish one tier from another. You create plans in the admin backoffice, and they are exposed through a public API so your pricing page and embeddable pricing widget read them live rather than hard-coding a table that drifts out of sync.
The important design point is that a plan is data, not code. You add a tier, change a price, or introduce an annual billing period by configuring a plan — not by editing billing logic. The engine reads the plan and applies the rules. That separation is what lets a non-developer adjust pricing without a deploy, and it is what keeps the billing code small enough to trust.
Selling internationally means money in more than one currency, and money is exactly the place where floating-point sloppiness turns into real accounting errors. VBWD's pricing is built on a unified price model: a value object that carries an amount, a currency, and — critically — a tax breakdown, and that is never silently rounded mid-calculation. Prices flow through the system as structured values, not as bare floats you hope stay consistent.
Concretely, there is a single way to get the price of anything sellable — a plan, a product, an add-on — and it returns a price object with its currency and its per-rate tax breakdown attached. Because every sellable resolves through the same path, a plan priced in euros and a product priced in another currency are handled by the same machinery, and the invoice that results carries the correct currency and tax on each line. You are not writing per-currency branches; you are asking each sellable for its price and letting the model carry the currency through.
Flat subscriptions answer "may this customer use the feature?" They do not answer "how much did they use?" For anything metered — API calls, AI generations, exports, messages — you need credit that depletes with consumption. VBWD ships a token system for exactly this. Customers acquire token bundles; your feature decrements them as it runs; when the balance is exhausted, the feature stops or prompts a top-up.
This matters most for AI features, where cost scales with usage and a flat monthly fee either overcharges light users or bankrupts you on heavy ones. With tokens you price the unit of work: an AI generation costs N tokens, a bundle of tokens costs a set price, and your margin is the difference. The token system also composes with subscriptions — a plan can grant a monthly token allowance, and customers can buy more on top. You get both the predictability of a subscription and the fairness of metered billing without inventing your own metering ledger.
A practical note from the platform's own design: token bundles and the credits they represent are first-class, so they show up in the invoice and reconcile like anything else you sell. Metered usage is not a bolt-on spreadsheet; it is part of the same billing record.
An invoice is the durable record of a transaction, and getting its lifecycle right is what makes your books trustworthy and your tax filings possible. VBWD models the full lifecycle: an invoice is raised for a charge, it carries line items, each line item carries its own per-rate tax breakdown, and the invoice moves through states as it is paid, and — where necessary — adjusted.
The per-line tax breakdown is not a detail you can skip. Different line items can attract different tax rates; a discount line has to carry negative tax so the totals reconcile; a refund has to net correctly against the original. VBWD's invoicing handles these by keeping tax at the line level and applying it consistently. Discount lines, for instance, carry a negative per-rate tax breakdown so that when the booking is totalled, the tax reconciles rather than drifting by a cent that an auditor will eventually find. This is the unglamorous correctness that separates a real billing system from a demo that adds numbers up and hopes.
Because invoices are events in the system, other parts of your product can react to them. When an invoice is paid, downstream handlers can grant access, provision a resource, send a receipt, or fire an outbound webhook. The invoice is not a dead PDF; it is a state machine that other features subscribe to.
The reason to have these as one engine rather than four libraries is that real transactions cross all of them at once. Consider a customer on an annual plan in euros who buys an extra token bundle and receives a promotional discount:
Every one of those steps is a place where a home-grown billing setup usually springs a leak — a rounding error, a currency mismatch, tax applied to the wrong base, a discount that does not reconcile. Having them in one engine means they are tested together and reconcile together.
Notice what is not in the billing engine: the payment provider. Taking money from Stripe, PayPal, or another processor is handled by payment plugins behind a common adapter, and the billing engine talks to that adapter, not to any specific provider. This keeps the money-movement concern swappable — you can change or add a processor without touching how plans, tokens, and invoices work. The billing engine decides what is owed; the payment plugin decides how it is collected. Keeping those separate is why a new payment rail is a plugin and not a rewrite.
The argument for using this rather than building your own is time and correctness. Billing is deceptively deep: the happy path is a weekend, and the long tail — proration, multi-currency tax, refunds, metered credit, reconciliation — is months, and it is exactly the part customers and auditors notice when it is wrong. VBWD's engine has already paid that cost. You configure plans, decide whether a feature is flat or metered, and connect a payment provider; the currency handling, tax breakdown, and invoice lifecycle come with it. Your engineering time goes into the product your customers are paying for, not into re-deriving how VAT interacts with a mid-cycle discount.
This is a billing engine, not a full finance suite. It produces correct invoices with proper tax breakdowns and a clean lifecycle, but it is not a replacement for your accountant or an ERP — you will still export to whatever system files your taxes and closes your books. Tax rates and rules are configuration you are responsible for setting correctly for your jurisdictions; the engine applies them faithfully, but it does not know your local law for you. And metered billing is only as accurate as the point where you decrement tokens — instrument that carefully, because an untracked consumption path is revenue you are giving away. Within those bounds, what you get is a billing core that handles the cases that usually break, correctly, from day one.
Plans define the contract, the unified price model carries currency and tax without rounding drift, the token system prices usage rather than mere access, and the invoice lifecycle records it all with per-line tax that reconciles — including the awkward cases like discounts and refunds. They are one engine because real transactions touch all of them at once, and separating the payment provider behind an adapter keeps money-movement swappable. You configure the pricing; the correctness is already built.
Create your plans in the admin app, decide flat-vs-metered per feature, connect a payment plugin, and read the token and pricing docs for the exact APIs.