What this prompt does
This prompt designs a B2B SaaS billing and subscription settings page and returns real components and states, not a sketch. It covers the current-plan card with renewal date and a clear cancel/downgrade path, a usage meter with an at-risk warning, a plan comparison table with proration notes, a payment-methods section wired to your provider, and a billing-history table with downloadable invoices and a tax ID field. The emphasis lands where support tickets actually originate: failed payments and proration.
The variables make the screen match your billing reality. [plans] populates the comparison table and upgrade CTAs. [provider] (for example, Stripe) wires the add/set-default/remove and card-expiry flows to a real API shape. [framework] sets the component conventions. [tax_handling] drives the tax ID field — EU VAT with reverse charge looks different from a flat sales-tax model, and the prompt builds the field per that input.
When to use it
- You are building a billing settings page for a B2B SaaS product
- You need the failed-payment and proration states designed, not just the happy path
- You want a plan comparison table with upgrade CTAs and a proration note
- Your payment provider needs add, set-default, remove, and card-expiry handling
- You need invoice history with status badges and downloadable invoices
- You handle tax IDs (such as EU VAT) and need that field built in correctly
Example output
The model returns a component tree with states for your framework: a current-plan card with renewal date, seat count, and cancel/downgrade path; a usage meter with an at-risk warning; a plan comparison table for your plans; a payment-methods section wired to your provider; and a billing-history table with status badges, downloadable invoices, and a tax ID field. Loading, empty, and failed-payment states are included, and it is responsive and keyboard accessible.
Pro tips
- List your real tiers in
[plans]so the comparison table and proration notes reflect your actual pricing - Set
[provider]to your processor; the payment-method flows depend on its API shape, especially card-expiry warnings - Describe
[tax_handling]precisely — EU VAT with reverse charge needs different field logic than a simple sales-tax setup - Get the failed-payment banner and downgrade confirmation right first; those states protect revenue more than visual polish
- Keep the at-risk usage warning; users who hit a plan limit without warning churn or file tickets
- Match
[framework]to your stack so the component tree and state handling slot in cleanly - Make the cancel and downgrade path obvious rather than buried; a hidden cancel flow generates chargebacks and support load instead of clean churn
- Use the proration note on the comparison table so users understand the mid-cycle charge before they upgrade, not after it lands on the invoice
