Packages

What ships together, and what each package owns.

The repo publishes four packages on one version line. They are released together, and an internal dependency is always the workspace version.

Each package’s modules are in the reference: Paykit, Paykit Polar, Paykit Stripe and Paykit Admin. A page there is one source module, generated from the JSDoc beside it.

What each one owns

@potion.run/paykit owns the model: the event log, the standing, the entitlement read, the catalog guard, the policies and the provider port. A host declares a catalog, builds a BillingStack, and calls the typed commands.

The provider packages own one vendor each. They create and reconcile the products, prices and meters the catalog describes, and they decode the vendor’s webhooks. Money movement stays behind the Payments port.

The admin package is a client of BillingAdminApi. It never owns billing state: the list, preview and verify are reads, and every write is a command with a command id.

Examples

• Billing example — the full Worker on D1: Api, console, MCP, checkouts, webhooks and a typed Tenant API over the catalog declarations.
• Memory example — the smallest deployment: MemoryStore and the manual provider, with no database or key.
• Polar example — PolarBilling provisions a product and hands its id to the Worker.
• Stripe example — StripeBilling provisions the prices and meters, and the Worker resolves the lookup keys it was given.
• Postgres example — the model on Postgres through Cloudflare Hyperdrive, with Alchemy’s SQL client and migration registry.
• Admin example — the console, a cookie session and pushed live reads.
• Auth example — Better Auth on D1, and the provider-neutral session resolver.
• TanStack example — a TanStack Start app whose billing UI is the Effect Atom client.