SaaS pricing page best practices: 12 tests judged on revenue

Only 4% of G2 product profiles list a price, according to G2's own 2025 audit. Yet 81% of buyers say they want to find pricing on their own (TrustRadius, 2022).

That gap is your opening. Most lists of SaaS pricing page best practices stop at one tip: show your price. This one gives you 12 changes worth testing. For each, you get what the evidence says and how to tell whether the test made you money.

Why judge a pricing page on paid sign-ups#

A pricing page can win on clicks and lose on money. The clearest public example is old but useful.

Server Density, a server monitoring tool, tested per-server pricing against packages starting at $99 a month. Free sign-ups fell from 6.92% to 5.19%. Total revenue rose from $394 to $833, because the average order went from $19.70 to $55.53 (VWO case study).

Judged on sign-ups, they'd have killed the winner. Notice the other lesson too: the test had only 20 and 15 paid upgrades. That's too few to be sure. Revenue doubled, but a few large orders could explain it.

So every test below gets two numbers: paid sign-ups and revenue per visitor. Trial starts are a leading signal, not the verdict.

12 SaaS pricing page best practices worth testing#

These are SaaS pricing page best practices as hypotheses. Each has a reason to test it, and a case where I'd skip it.

1. Show prices instead of "contact us"#

Nielsen Norman Group's research found business buyers rank pricing as the information they need most. "We watch participants go to competitors' sites when websites do not show prices," wrote Hoa Loranger (NN/g). In TrustRadius's survey, 71% said visible pricing would make them more likely to buy (TrustRadius).

I'd show prices for every self-serve plan. The opposite case: deals above roughly $30k a year where the price depends on scope. Even then, NN/g suggests a "starting at" price or a typical example.

2. Default the toggle to annual or monthly#

Defaulting to annual shows a lower monthly number and brings cash up front. It can also scare off buyers who want to try a month first. No public study settles this for SaaS.

Test it, and judge on 90-day cash collected and paid sign-ups together. If you're cash-constrained, annual default is worth a small drop in sign-ups.

3. Cut the number of plans#

More plans mean more thinking before paying. Stripe's own embeddable pricing table allows at most four products per billing interval (Stripe Docs). That's a sensible ceiling.

I'd start with three self-serve plans plus a sales-led tier. Go to two if most buyers pick the same plan anyway.

4. Highlight one plan#

A "most popular" badge steers attention. Stripe's pricing table has a setting for it. Highlight the plan you want most people on, not your most expensive one. Then check whether the mix of plans sold moves, and whether total revenue moves with it.

5. Add a feature comparison table#

Cards show the headline. A table below answers "does Pro include SSO?" without a sales call. Keep the cards short and push detail into the table. If your table runs past 30 rows, group it and collapse the rarely used parts.

6. Put an FAQ on the page#

The pricing page is where objections peak: cancel terms, seat changes, refunds, what counts as a "user." Answer them under the plans. This also gives you text that search engines and AI answers can quote.

7. Add a usage calculator, or don't#

For usage-based pricing, a calculator seems kind. NN/g found configurators "complex, time-consuming, and error-prone," used by few people, and suggested representative scenarios instead (NN/g). Stripe's embeddable table doesn't support usage-based pricing at all.

I'd test three worked examples ("a team of 10 sending 50,000 emails pays $X") against a calculator. Keep the calculator only if it wins on paid sign-ups.

8. Put trust signals next to the button#

Security badges, a named customer quote, "cancel any time" and refund terms work best near the click, not in the footer. Use only real logos and real quotes you have permission to show.

9. Say who each plan is for#

Write one line per plan: for solo founders, for teams of 5–50, or for companies that need SSO and audit logs. A line like this saves the buyer from decoding feature lists. It's one of the cheapest tests on this list.

10. Choose the call to action: trial, free plan or demo#

The button decides your funnel. A card-required trial, a no-card trial, a free plan and "book a demo" bring very different people. Compare the models in free trial vs freemium: which brings more paying customers before you test button copy.

If buyers need a demo, you can still show prices. Then send trial users into trial follow-up emails that turn sign-ups into paying customers, because the page only gets them to the door.

11. Show local currency#

Paddle reports that iMobie's conversion rose 23% in France, 20% in Germany and 10% in Japan after localizing prices (Paddle). That's a vendor case study, and it bundled other checkout changes. Stripe's Adaptive Pricing converts prices in 150+ countries, but customers pay a 2–4% conversion fee (Stripe Docs).

I'd test this once more than about 20% of pricing-page visitors come from outside the US.

12. Make add-ons and limits visible#

Extra seats, overage rates and paid onboarding belong on the page. People see companies that hide costs as "evasive and untrustworthy," NN/g warns. A surprise at checkout or on the first invoice costs you refunds and churn later.

Which test to run first: a table#

Start where the change is cheap and the possible effect on paid sign-ups is large.

What I'd check first: the share of pricing-page visitors who reach checkout. If it's tiny, fix clarity (tests 1, 6, 9) before touching layout.

How to judge a pricing page test with Stripe#

Pricing page conversion to paid is low, so tests need more traffic than most teams expect.

Sample size. At 95% confidence and 80% power, here's roughly how many visitors each version needs (Evan Miller's calculator gives the same ballpark):

If you get 3,000 pricing-page visitors a month, you can only detect big changes. Test bold ideas, not button colors. Or run a before/after with a holdout, as in how to tell if a marketing change really worked.

Tie the variant to the payment. Pass the test variant and visitor ID into Stripe. The pricing table and Checkout accept a client_reference_id of up to 200 characters (Stripe Docs). Then count paid subscriptions per variant from Stripe, not from your testing tool.

Wait out the trial. With a 14-day trial, a test isn't done when the last visitor enters it. Wait 14 more days, plus time for the first charge.

Watch revenue per visitor, not only rate. Server Density's lesson again: fewer, larger customers can beat more small ones.

Check churn a month later. A cheaper default plan can lift sign-ups and still lose money if those customers leave.

How to do this in Kratly#

We built Kratly so a pricing test ends with a revenue number, not a click number.

1. Connect your site and Stripe. Kratly ties pricing-page visits to the subscriptions they turn into.
2. Measure each change on revenue. Kratly compares paid sign-ups and revenue from pricing-page visitors before and after a change, against a control.
3. See where visitors drop. A funnel from pricing page to checkout to first payment shows which step loses the most.
4. Approve and log the change. You approve each change; it's logged and can be reversed.

The pillar guide explains the wider idea: autonomous growth ties every page and campaign to the customers who pay. Your pricing page also needs traffic from people ready to buy, which bottom-of-funnel SaaS SEO pages bring.