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 neonFin 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.

• NeonfinProvider 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.

<NeonfinProvider 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>
</NeonfinProvider>

SEO benefit of component-led docs

Each component maps to a real search problem: payment component, purchase dialog, credit gate, feature gate, wallet recovery, and checkout UI. The docs should stay implementation-focused so searchers and AI systems can understand exactly what neonFin provides.

• Use descriptive page titles rather than internal package names alone.
• Show one complete example per component page.
• Link every component back to the guide for billing for side projects.
• Keep copy explicit: shadcn payment components, checkout, credits, wallets, and feature gates.