@fonderie/vue-billing

@fonderie/vue-billing

Vue 3 composables for Fonderie billing — usePlans, usePlan, useSubscription, useCheckout, useBillingPortal, useUsage, useRecordUsage, in-app card management (usePaymentMethod, useSetupPaymentMethod, useSavePaymentMethod, useRemovePaymentMethod), and usePurchasePack (buy a credit pack by charging the saved card — no redirect). Thin bindings over @fonderie/client: reactive refs for loading/error/data state and the request itself, nothing else. Bring your own UI.

Install

npm install @fonderie/vue-billing

One client at the root (recommended)

Install the plugin from @fonderie/vue once (or call provideFonderie(client) in a root setup()) and every composable resolves the client by injection — no client argument at call sites:

import { FonderiePlugin } from "@fonderie/vue";

createApp(App).use(FonderiePlugin, client).mount("#app");

// in any component setup():
const { ...state } = usePlans();

Passing a client explicitly (as below) still works everywhere and takes precedence over injection — handy in tests and multi-client apps.

Use

<script setup>
import { FonderieClient } from '@fonderie/client';
import { usePlans, useCheckout } from '@fonderie/vue-billing';

const client = new FonderieClient({ baseUrl: 'https://api.example.com/v1' });
const { plans } = usePlans(client.billing);
const { checkout } = useCheckout(client.billing);

async function choose(planName) {
  window.location.href = await checkout({ plan: planName });
}
</script>

<template>
  <ul>
    <li v-for="plan in plans" :key="plan.id">
      {{ plan.name }}
      <button @click="choose(plan.name)">Choose</button>
    </li>
  </ul>
</template>

Each composable takes the same BillingClient instance (client.billing) — construct one FonderieClient at the app root and pass it down (provide/inject or a prop). The client's access token is shared with client.auth automatically, so signing in via @fonderie/vue-auth is enough to authenticate billing requests too. Billing by workspace instead of by user? Call client.billing.setWorkspaceId(id).

Manage a card in-app (no redirect)

Let users add a card without leaving the site. useSetupPaymentMethod resolves to a provider SetupIntent client secret you hand to a Stripe Payment Element; after it confirms client-side, useSavePaymentMethod records the card as the default. usePaymentMethod reads the card on file and useRemovePaymentMethod detaches it.

import { useSetupPaymentMethod, useSavePaymentMethod } from '@fonderie/vue-billing';

const { setup } = useSetupPaymentMethod();
const { save } = useSavePaymentMethod();

const clientSecret = await setup(); // → mount a Stripe Payment Element with it
// after the element confirms the SetupIntent client-side:
await save(paymentMethodId); // records it as the default

The Payment Element and the publishable key live in your app (a generic package can't own them). Want pre-built screens instead of wiring your own pricing table? See @fonderie/vue-billing-screens — its SubscriptionScreen shows and removes the card and delegates add/update via an add-payment-method emit.

Why this exists

You've shipped this plumbing before — auth, teams, billing, messaging — and the next project will ask for it again. Fonderie packages it once: plain TypeScript modules for @fonderie/core, PostgreSQL-backed, self-hosted, MIT. No external control plane, no per-seat anything. Register the modules you need; skip the ones you don't.

This package owns the Vue binding for billing — reactive state management around @fonderie/client, nothing more. No business logic lives here; it lives in @fonderie/billing on the server.

Browse the whole set at fonderiejs/fonderie · follow @fonderiejs

License

MIT © Fonderie, Inc.