Billing UI you install, then own
shadcn-compatible components over billing-kit’s types: the code lands in your repo with npx shadcn add, styled by your tokens, editable like anything else you wrote. The license is per developer seat — not per end user, not per render.
The registry
pricing-tablePlans, tiers and the pay-as-you-go line, rendered from your own plan objects.
usage-meterLive usage against included allowances — the number your customers check daily.
ledger-viewThe double-entry ledger, humanized: every charge traceable to its events.
checkoutProvider-hosted checkout hand-off with the states your support team will ask about.
invoice-listSettled periods with their exact amounts — the same Money the core computed.
superadminThe cross-tenant operator view: accounts, balances, interventions, audit trail.
Why code, not an SDK
A billing UI is where product opinions concentrate — what a plan is called, which number is largest, what happens on a failed payment. An SDK makes those our decisions and your feature requests; installed code makes them yours and a diff. The components stay thin over billing-kit’s own types (Money, Quantity, ledger entries), so the numbers on screen are the numbers the core computed — never re-derived in a frontend.