How to Price a Platform Fee so It Reads as Honest Rather Than Hidden

We worked on a travel booking product and made a decision that felt generous at the time. The platform charged a Stripe booking fee, and we folded it into the headline price so travellers saw one number. Nothing was added at the end. The fee sat inside the total, paid for and accounted for, and the screen looked calm.

Even a small unexplained fee can do real damage to trust at the moment of payment.

Travellers read that calm number as a warning. With no fee anywhere on screen, people assumed one was waiting for them further down the flow, and some of them slowed right at the point we had tried to make easy. So we broke everything out and showed each line, fee included. They saw more information and trusted the price more.

This article is about pricing a platform fee so it reads as honest. Where the fee first appears, what you call it, who carries it, what your payment setup lets you show, and what happens to it when somebody cancels. Most of it comes from booking and marketplace products we have built, including the parts we got wrong first and then rebuilt.

What People Already Expect a Platform Fee to Look Like

People arrive at your checkout carrying a picture of how products like yours charge for things. That picture comes from every other app they have used, and it is already set before your first screen loads. On the travel product, Simon described the difference between someone booking a holiday on a website and someone using an app that is all about travel. In the app, people expect a platform fee. They are not pleased about it, they simply know it is there.

The category sets the rules

A marketplace, a booking platform and a direct brand shop get judged against different habits. Buy a candle from a home and interiors brand and one price with delivery underneath feels right. Book a table, a trip or a tradesperson through a platform and people look for the line that shows what the platform takes. Leave that line out and the screen starts to feel incomplete.

So the first question is what this category has taught your buyer to look for. Matching that picture costs nothing and buys a lot of quiet confidence.

Why a Single Clean Total Backfires

On a marketplace checkout project we ran, confusion about fees caused real hesitation. People could not tell whether the fee was added on top of the price or already sitting inside it, and that uncertainty was enough to stall them. As Simon put it, even a small financial difference can make quite a big impact on trust. The amounts were tiny. The doubt was not.

There is a real danger that teams oversimplify. They strip the price down to one number to reduce effort for the buyer, and in doing so they remove the information the buyer was using to check themselves. What we should be doing is layering, giving people a plain total with the detail available underneath for anyone who wants it.

Simplicity and clarity are different things

One number is simple. One number with no way to see inside it is a request to take your word for it, at the exact moment somebody is deciding whether to trust you with a card. Showing the breakdown costs a few lines of screen and answers the question before it forms.

Where the Fee Should First Appear in the Journey

On a dating product we worked on, the flow asked people to share their precise location before they had viewed a profile or sent a single message. We rebuilt it so you saw the profile, talked through the inbuilt messaging, and shared location only once you felt confident enough to meet. The order of the asks changed the outcome, with no change to what was being asked.

Money follows the same logic. A fee revealed late reads as something you were saving up. The same fee, shown while someone is still browsing, reads as a fact about how the platform works.

Show the fee while people are still browsing, long before you ask anyone for a card.

A sequence that holds up under pressure looks like this.

1. Search and listing results show the price with any unavoidable fee already in it.
2. The detail page breaks that price into its parts, fee named and explained in one line.
3. The basket or booking summary repeats the same breakdown, with the same wording.
4. Checkout shows the identical total, so nothing moves while the card is out.
5. The confirmation and the receipt carry the breakdown through, for later reference.

Naming the Fee So It Explains Itself

A fee called "service fee" invites the question "what service?" and most people answer it themselves, usually unkindly. The name is doing the explaining whether you planned it that way or not. So reframing the terminology is some of the cheapest work available to you.

Good names describe what the money buys in words the buyer already uses.

• Booking fee, for the cost of holding and confirming the reservation.
• Platform fee, for running payments, support and the protections around them.
• Payment processing, for the card charge you pass on.
• Cleaning or preparation fee, for work somebody physically does.

Write one short sentence under the fee name saying where the money goes, in plain words, and keep that sentence identical everywhere the fee appears.

Vagueness is what people punish. A fitness studio charging a booking fee that covers the cost of holding your space and refunding no-shows has explained itself. A fee with no description attached asks the buyer to invent a reason, and the reason they invent is that you wanted more money.

Deciding Who Pays: Buyer, Seller, or Both

This decision gets made in a finance meeting and then lands, unexplained, on a pricing screen. The commercial maths matters, and so does what each model teaches the buyer about you.

Seller-paid looks kindest and often is. It also pushes the cost somewhere the buyer cannot see, and sellers respond by raising their listed prices. The fee still exists. It has simply moved into a number nobody can question.

Buyer-paid survives scrutiny best, on the condition that it is named, explained and visible early. A jewellery marketplace charging buyers a small platform fee with a clear line about buyer protection is making an argument. A platform hiding the same amount inside a seller's price is making a bet.

What Your Payment Setup Actually Lets You Show

Pricing design runs into payment infrastructure faster than people expect. Integrating Stripe Connect, we found the account types carry quite different constraints. Express accounts push money out to sellers almost immediately, which did not suit the product we were building, and getting different behaviour meant more custom work in the flow.

Control costs complexity

Simon's line from that project has held up since. "The more control you have over the payments, the more complex the flows become." The balance we were after was getting exactly the payment behaviour the product needed without customising so far that we lost the benefits of Stripe's default handling.

Constraints also arrive from directions you did not choose. On an alcohol buying and selling platform we built, we were pushed to embed existing web elements rather than build a proper API layer. That decision added work across the whole project, and because the budget stayed fixed, features came off the plan near the end. Parts of the checkout presentation were simply not ours to control any more.

So before you promise a pricing display, check what your payment setup lets you render, split and refund. The honest version of your price screen has to be buildable.

When the Money Moves, and Why That Belongs in the Price

On a property maintenance platform we worked on, the product connected landlords, tenants and tradespeople. Job specs went up, progress was geotagged as work happened, and payment released on completion. We looked at third-party escrow services and found legal complications for the client, so we used Stripe Connect with delayed payouts and treated the product as a marketplace app. Simon's summary of it was that we decided to do delayed payouts on Stripe, staying within the financial regulations for products like this while still giving us the end result we wanted.

That timing is part of the price story. A fee charged to hold money safely until a job is finished is a different thing from a fee charged for a payment that cleared instantly.

Holding funds until the work is done changes what the fee means, so say that on the price screen.

Tell people when the money leaves their account, when the other party receives it, and what has to happen in between. A tradesperson wants to know when they get paid. A landlord wants to know the money sits still until the job is signed off. One line each, in the flow, answers both.

Splitting a Booking Across Several Payers

On the group travel OTA product we worked on, we redesigned the checkout so the data-entry burden spread across everyone on the trip. Rather than the lead booker typing in passport numbers and personal details for the whole group, we built the ability to invite individual travellers to fill in their own information, with the booking updating as each person finished their part. The lead booker did the minimum needed to reserve, and the rest arrived in parallel.

That worked because the product was aimed at friendship groups and colleague trips. Simon was clear about the limits of it. A family booking, where a parent is entering children's details, does not fit the same pattern, so manual entry stayed available for anyone who needed it. The shared version was an opt-in improvement for people it suited.

When a booking splits across payers, show each person their own share of the fee and the group total on the same screen, so nobody thinks the fee has been charged twice.

Fees get messy here. Four people paying a quarter each need to see one platform fee divided four ways, with the arithmetic visible. Charge the fee per payer without saying so and you have built a surcharge for having friends.

The Legal Floor: Drip Pricing and Price Transparency Rules

UK consumer rules have moved steadily against drip pricing, the pattern where an advertised price grows as you move through a flow. The principle is straightforward. Fees that every buyer has to pay belong in the price you show first, not in a line that arrives after someone has committed their time.

Optional extras are treated differently, because the buyer chooses them. Compulsory charges are part of the price, whatever you call them. So a hotel booking that adds a mandatory resort fee at the final step has a problem that no amount of good wording fixes.

The law is the floor, not the target

Meeting the rules keeps you out of trouble. It does not get you the confidence we saw on the travel product, where the breakdown made people more comfortable with a total they had already accepted. That came from showing the parts, repeating them consistently, and explaining each one in a sentence a nine-year-old reads without stopping.

Treat the regulation as the minimum standard and design past it. The buyer's test is simpler than any statute. They want the number at the start to match the number at the end.

Refunds, Cancellations, and What Happens to the Fee

A fee that quietly stays behind during a refund undoes everything the pricing screen earned. Somebody cancels a wellness retreat, sees most of their money return, and spots a small amount missing. Now they are reading your terms in a bad mood, looking for the trick.

So the refund rule belongs next to the fee itself, at the point of purchase. Non-refundable fees are defensible when the work has genuinely been done and the buyer was told clearly before paying. Refundable fees are easier to live with and worth the cost in many categories.

Put the refund behaviour of each fee in the same tooltip or line that explains the fee, rather than in the terms page nobody opens.

Timing deserves the same treatment. On products with delayed payouts, like the property maintenance platform, a cancellation before release is clean and a cancellation after release involves somebody who has already been paid. Say which situation applies, in the flow, in the words people use. Then say it again on the confirmation email, where the buyer looks when something goes wrong.

Testing Whether Your Pricing Reads as Honest

Testing pricing in a usability session gives you flattering answers. Participants are reviewing a screen, not spending their own money, so they assess the fee rationally and tell you it seems fair. Live analytics tell a different story. People genuinely about to transact are in a different emotional state, and something that looked fine in the session erodes trust just enough for them to leave the checkout.

Simon's audit principle works better here than any score. If you had to tell people exactly what this fee is and why you charge it, do they still go through with it? A no means the wording is carrying the purpose, so the structure needs changing.

If the honest sentence beside your fee loses you the booking, fix the fee.

A practical run of checks for an existing flow.

1. Screenshot the price at every step and compare the totals side by side.
2. Read each fee name aloud and answer the question it provokes.
3. Watch drop-off by step in live data, especially the screen where the fee first appears.
4. Read support tickets and reviews for the phrase "hidden fee" and count what prompted it.

When the Fee Itself Is the Problem

Sometimes the wording is fine and the fee is not. If every honest description of a charge makes it sound worse, the charge is doing something you cannot defend, and design work becomes a way of delaying that conversation.

The signs are reasonably consistent. The fee has no name that survives a follow-up question. It covers a cost the buyer assumed was part of the price. It scales with the order value while the work behind it stays the same. Or it exists because margin went missing somewhere else and this was the quietest place to recover it.

On the marketplace checkout project, the amounts causing hesitation were small. The size of the charge had very little to do with it. People stalled because they could not work out what the fee was for or whether it had already been counted, and nobody proceeds while holding that question.

Fixing that means changing the structure. Fold the charge into the price and raise the base. Move it to the seller side with the reasoning made plain to sellers. Or drop it, and find the margin somewhere a buyer can understand.

Conclusion

The travel product taught us the lesson we now start from. We hid a fee inside a total out of kindness, and travellers read the absence as a threat. Breaking every line out gave them more to look at and more confidence in what they were paying, which is the opposite of what the simpler screen was meant to achieve.

So the work is mostly ordering and wording. Show the fee early, while people are still browsing. Name it so the name answers the obvious question. Say who pays it, when the money moves, and what happens to it if the booking falls through. Keep the same number and the same words from the first screen to the receipt. Check what your payment setup lets you build before you promise any of it.

None of that requires a clever interface. It requires deciding that the buyer is allowed to see how your platform makes money, and then designing as though that were a comfortable thing to show.

If you are working through a fee structure on a booking or marketplace product, we are happy to look at it with you. Let's talk about your pricing flow.

Frequently Asked Questions