shadcn payment components

Why payment UI should live in your app

Billing touches the most sensitive parts of a product: pricing, locked states, empty balances, renewals, and support recovery. A hosted widget can be fast, but it often feels bolted on. The shadcn model works better for small developer products because the component source lands in your repository.

• Review the component code before shipping it.
• Change copy, layout, and styling to match the product.
• Keep checkout prompts close to the feature they unlock.
• Avoid building balance displays and purchase dialogs from scratch.

The core vantezzen/pay components

The registry gives you the common payment UI pieces most small apps need. They can be used together for a complete flow or separately when you want custom screens.

• PayProvider loads wallet state and resumes checkout confirmation.
• RemainingCredits shows a live balance for the current wallet.
• PurchaseButton and PurchaseDialog list offers and start checkout.
• CreditGate renders paid UI only when enough credits exist.
• FeatureGate renders UI only when a subscription, one-time purchase, or grant unlocks it.
• WalletButton lets users copy, restore, transfer, and manage a wallet.

A simple paid action

For a credit-based action, put the provider around the paid part of the app, show the balance, then gate the action by the number of credits it costs.

<PayProvider publishableKey={publishableKey}>
  <div className="flex items-center gap-3">
    <RemainingCredits productSlug="video-minutes" />
    <WalletButton />
  </div>

  <CreditGate productSlug="video-minutes" cost={10}>
    <Button onClick={() => deduct(10)}>
      Process video
    </Button>
  </CreditGate>
</PayProvider>