By Mehdi HassanHow should a fintech company present fees on its website?
A fintech company should present fees in a single, complete table that a customer can read before signing up, with the most common fee first and each condition written beside the number it affects. Hiding fees doesn't make them smaller. It just moves the surprise to a moment when the user is already annoyed.
Fees are the most sensitive copy on a fintech site because they sit where marketing and regulation meet. Marketing wants a short, attractive number. Compliance wants every charge stated accurately. The good news is that a well-designed fee table serves both. This article walks through real, publicly visible patterns and what each one does well. For the wider trust picture, see our hub on fintech website design.
Which fintech pricing page examples get fee disclosure right?
The fintech pricing pages worth studying share one habit: they answer "what will this cost me?" in the first screen, then let the user go deeper. Here are six well-known examples and the device each one uses.
Company | Pattern | Why it works |
|---|---|---|
Stripe | Headline rate per transaction, then add-on fees by product | The common case is instant; edge cases are still listed |
Wise | Fee and exchange-rate calculator before signup | Users see their own transfer cost, not a range |
Square | Rates split by how you take payment | Each merchant finds their row in seconds |
Revolut | Plan comparison with allowances and limits | Shows what's free up to a point and what isn't |
Mercury | Plan tiers with what each includes | Clarifies what a free business account covers |
Ramp | Free core product, paid tier compared beside it | Removes the fear of a hidden catch |
Stripe: the common case first
Stripe's pricing page has long led with a single headline rate for card payments, then broken out other payment methods, international cards and add-on products below. The lesson is order: most visitors want the main number, and specialists can scroll for the rest. Nothing is hidden, but nothing competes with the answer most people need.
Wise: a calculator instead of a schedule
Wise puts a calculator at the center: you enter an amount and currencies, and it shows the fee and the rate before you sign up. It turns a complex fee schedule into one personal number. For any product where cost depends on amount, a calculator is more honest and more persuasive than a table of percentages.
Square: rows by situation
Square has organised its processing rates by how the merchant takes payment: in person, online, keyed in and so on. Each visitor finds their own row instead of decoding a matrix. Organising by the customer's situation rather than by your internal product names is the single easiest improvement most fintech pricing pages can make.
What makes a transparent fees page readable?
A transparent fees page is readable when every row answers three things: what the fee is for, how much it is, and when it applies. If any of the three lives somewhere else, such as a footnote or a PDF, the table stops being transparent even if it's technically complete.
- Name fees in customer words: "Sending money abroad," not "cross-border FX markup."
- One condition per row: if a fee only applies over a limit, say so in the same row.
- Show zero fees explicitly: "Free" in a cell is a selling point and a disclosure at once.
- Use real numbers, not "from": "from" invites suspicion. Show the range and what moves it.
- Date the table: a visible "fees effective" date tells users and regulators the page is maintained.
These rules apply to consumer and business products alike, though a B2B fintech website often needs an extra layer for volume or custom pricing. Even then, show the standard rate and say when custom pricing starts.
How do you make a fee table compliant and still friendly?
You make a fee table compliant and friendly by treating the approved fee language as fixed content and designing everything else around it. Counsel decides what each fee must say. Design decides how it's grouped, how it scans on a phone and where the plain-language explanation sits.
List every fee from the source of truth
Start from the fee schedule in your terms or account agreement, not from the marketing deck. Every fee there must appear on the page or be linked.
Group by customer situation
Sort fees by what the customer is doing, such as paying, sending or withdrawing, the way Square groups by payment method.
Write a plain line for each
Add a one-line explanation in customer language beside each fee, then send the whole table to counsel as one document.
Design for long wording
Approved text often comes back longer. Build rows that wrap cleanly on mobile instead of truncating.
Publish from one CMS source
Store the table once and reuse it on pricing, product and help pages so they can't drift apart.
Where your fees sit on the rest of the site matters too. Our guide to fintech website compliance covers footer language and disclaimers, and our fintech landing page guide shows how to bring a short fee summary onto a campaign page.
Should a payments pricing page use a calculator?
A payments pricing page should use a calculator when the cost depends on amount, volume or currency, because a calculator gives each visitor their real number. When fees are flat and few, a plain table is clearer and a calculator just adds clicks.
Pros
- Shows each user their own cost in one step
- Turns a complex schedule into one honest number
- Doubles as an interactive comparison with alternatives
- Keeps visitors on the page longer, thinking about their own case
Cons
- Needs engineering and testing to stay accurate
- Must use the same rates as the published fee table
- Can hide the full schedule if it's the only thing on the page
- Every rate change means updating logic, not just copy
A worked example of calculator plus table
For example, suppose a startup offers international payouts with a percentage fee and a small fixed fee per transfer. The page opens with a calculator: amount, destination currency, and the result showing fee, rate and amount received.
Directly under it sits the full fee table, sourced from the same CMS entry the calculator reads its rates from. A line between them says "The calculator uses the fees below. Fees effective from [date]." Users get a personal answer, and compliance gets one source of truth that both elements share.
What can fintechs learn from SaaS and AI pricing pages?
Fintechs can borrow the structure of good SaaS and AI pricing pages, such as tiers, comparison tables and FAQs, but not their tone about fine print. A SaaS company can say "contact us" for enterprise pricing. A consumer fintech usually can't be vague about fees that apply to everyday accounts.
Our SaaS pricing page guide covers tier design and plan comparison in depth, and our AI pricing page guide shows how to explain usage and credits, which maps closely to transaction-based fees. Take the layout lessons and keep fintech's stricter standard for completeness.
