By Mehdi HassanYour pricing page persuades people to sign up. After that, almost every revenue decision happens inside the product: when a team hits a seat limit, when a trial ends, when usage creeps toward a cap. Those moments are designed far less carefully than the pricing page, and they decide whether users upgrade happily or leave annoyed. We design both the pricing page and the product, so this guide connects the two. It's part of our guide to SaaS product design.
What is good SaaS billing UX?
Good SaaS billing UX is the design of every in-app moment where plans, usage and payment meet the user's work: the billing page, upgrade prompts, paywalls on premium features, usage meters, limit-hit states, trial endings and failed payments. It's good when users always know what they have, what they'll pay and what changes if they upgrade.
Moment | User's question | What the design must answer |
|---|---|---|
Premium feature clicked | Can I use this? | Which plan includes it and what it does for me |
Usage nearing a limit | Will I run out? | Current usage, the limit and when it resets |
Limit reached | What happens to my work? | That work is safe, and the options to continue |
Trial ending | What will I lose? | Exactly what changes on which date |
Payment failed | Am I locked out? | Grace period, consequences and a one-click fix |
Plan change | What will I pay? | The new price, proration and next charge date |
How do you design an upgrade flow in a SaaS app?
Design an upgrade flow so it starts from the user's task, shows the one plan that solves their need, states the price and what changes, and returns them to the task once the upgrade is done. The fewer steps between "I need this" and "I have this", the better.
Trigger from the task
Show the prompt when the user tries something their plan doesn't include, not as a generic banner on every screen.
Recommend one plan
Highlight the cheapest plan that solves their current need. Link to the full comparison for anyone who wants it.
State the price and the change
Show the new price, proration and the next charge date before the confirm button.
Use the card on file
If there's a payment method, confirm in one step. If not, collect it inline rather than sending users to a separate site.
Return to the task
After upgrading, take users back to exactly what they were doing, with the feature now available.
The prompt should be written around the outcome. "Add 5 more seats to invite your whole team" works better than "Upgrade to Pro", because it's about the user's goal, not your plan structure. Our guide to UX writing for SaaS covers this outcome-first style for buttons and messages.
How should in-app paywalls work in SaaS?
In-app paywalls in SaaS should let users see and understand a premium feature before asking them to pay, and they should never block access to the user's own existing data. Soft paywalls, which preview the feature or allow limited use, generally feel fairer than hard walls that appear with no context.
Pattern | How it works | Use it when |
|---|---|---|
Visible but marked | Premium features show a small plan badge | You want users to discover what higher plans offer |
Preview | Users see a sample or read-only version | The value is easy to show, like a report or analytics view |
Limited use | A few uses free, then upgrade | The feature has a clear per-use value, like exports or AI credits |
Hard wall | Feature blocked until upgrade | The feature is costly to provide or is an admin capability |
How do you design usage meters and limits?
Design usage meters to show current usage, the limit and the reset date in one glance, and place them where usage happens as well as on the billing page. Warn users ahead of the limit, so reaching it is never a surprise in the middle of important work.
- Show the numbers. "7,400 of 10,000 credits used, resets on 1 November" beats a bar with no labels.
- Warn early. Show a warning as users approach the limit, and email admins as well as the user.
- Put meters in context. Show seat usage on the members page and credit usage next to the feature that consumes credits.
- Explain what counts. If some actions use more credits than others, say so before the action runs.
Usage-based pricing, common in AI products, makes this harder because consumption is less predictable. Our guide to AI pricing page design covers how to explain credits, seats and usage clearly, and AI product UX covers how to show cost inside AI features.
What should happen when a user hits a plan limit?
When a user hits a plan limit, their current work should be saved or allowed to finish, and they should see a clear message with the options to continue: upgrade, buy a top-up, wait for the reset or remove something. The limit should interrupt the next action, not destroy the current one.
Before | After |
|---|---|
Limit reached. Upgrade now | You've used all 10,000 credits this month. Your draft is saved. Add credits now or wait until 1 November |
You can't add more members | Your plan includes 5 seats and all are in use. Add a seat for this invite, or remove an inactive member |
Feature unavailable | Scheduled reports are on the Team plan. Upgrade to send this report every Monday |
If the user isn't allowed to upgrade, such as a Member in a team where only the Owner manages billing, don't show an upgrade button they can't use. Show who can upgrade and let them send a request. Our guide to roles and permissions UX covers that pattern.
How to handle trial endings and failed payments
Trial endings and failed payments are both limit moments with a date attached. For trials, tell users several days ahead exactly what changes on which date, what happens to their data and which plan matches what they've been using. For failed payments, say the card was declined, how long the account stays fully active, what happens after that and how to fix it in one step. In both cases, address the person who can act, usually the owner or billing admin, and keep a calm, factual tone. Alarmist copy about failed payments often reads as a scam and gets ignored.
How do you keep in-app billing consistent with your pricing page?
Keep in-app billing consistent with your pricing page by using the same plan names, limits, feature names and prices in both places, ideally from one shared source of truth. Any mismatch, such as a feature listed on the pricing page but named differently in the app, makes users doubt what they're paying for.
Treat your plans as content, not hard-coded strings in a dozen screens. A single plan definition that feeds the pricing page, the billing page, the upgrade modal and paywall badges stops drift as plans change. Our guide to SaaS pricing page design covers the public side, and B2B SaaS UX principles explains why one name per concept matters so much here.
Where billing lives in your navigation also matters: it belongs in workspace settings, visible to the roles that can act on it, which SaaS information architecture covers. If your upgrade moments need a redesign, they're a well-contained scope for our $3,000 brand and design sprint, which includes 10 website or product explorations.
