Billing for side projects

What side project billing actually needs

A small paid tool needs more than a checkout link. It needs products, prices, a way to know who paid, webhook fulfillment, access checks, customer recovery, and a tiny admin surface when something goes wrong.

• Checkout creation for one-time purchases, credit packs, and subscriptions.
• Webhook verification so payment state turns into app access.
• Wallets or external user mapping so access survives refreshes and devices.
• UI for balances, purchase prompts, feature gates, and billing portal links.
• A dashboard for orders, wallets, providers, products, and support adjustments.

The division of responsibility

Keep the payment provider responsible for payment processing, invoices, taxes, cards, refunds, and subscription billing. Put vantezzen/pay between your app and that provider so your product code only has to ask simple questions: can this user buy, spend, or access this feature?

• Stripe or Polar owns money, invoices, tax behavior, and payment methods.
• vantezzen/pay owns projects, products, prices, wallets, credits, gates, and fulfillment.
• Your app owns the product experience and calls a small client API.

A minimal integration path

Start with the smallest useful path: one project, one provider, one product, one price, and one gated action. Add subscriptions, one-time feature unlocks, or external auth only when the project actually needs them.

• Create a vantezzen/pay project for the app you want to monetize.
• Connect Stripe or Polar once from the provider screen.
• Create a product and price that match what the user buys.
• Install the shadcn registry components into your app.
• Show a balance, open checkout when needed, and deduct credits when work starts.

const { deduct } = useCredits();

<CreditGate cost={10}>
  <Button onClick={() => deduct(10)}>
    Process file
  </Button>
</CreditGate>

When this is the right fit

vantezzen/pay is intentionally strongest for small developer products: AI wrappers, generators, file processors, internal utilities, indie SaaS experiments, templates, and tools that are useful enough to charge for but too small to deserve a bespoke billing system.

• You want to charge in an afternoon, not turn billing into a sprint.
• You ship multiple small tools and want one shared billing service.
• You want payment components that live in your codebase and match your theme.
• You do not want to force auth just to sell credits or access.