Showing Prices on a Marketplace: How to Keep Offers Comparable
Showing prices on a marketplace is the job of making offers from different sellers comparable, which means deciding which of several numbers the buyer sees and which one they will pay.
A shared product page exists so that the buyer can compare offers. All of that value lives in a single number on the screen. If that number answers a different question from the one the buyer was asking, the comparison only looks like a comparison.
This article breaks down:
- Which 4 numbers does a buyer call "the price"?
- How do you put delivery into the comparison?
- Why must a unit price be a number?
- Net or gross: which one does the catalog hold?
Key insights
- The four numbers a buyer calls "the price" are the goods on their own, the goods with delivery, the price per unit, and the lowest price in a range.
- Put delivery into the comparison as the amount due, as far as you can know it at that point, with a plain sentence on the same line saying when it will change.
- A unit price must be a number with its unit of measure because it is the only way to compare a pack of twenty-four with a single can.
- The catalog holds one convention, net or gross, and converts on the way out, so the same offer means one thing to everyone who reads it.
What does a buyer compare when they compare prices?
Two offers of the same product: €100 and €90. The cheaper one charges €20 for delivery, the more expensive one delivers for free.
The buyer who picked €90 pays €110. That is the higher of the two bills.
Not because anybody cheated them. Because you showed them a number that is not an answer to their question.
Your platform shows prices, because the price is what the seller typed into the offer. The buyer compares amounts payable, because that is the only number that concerns them.
Comparability therefore does not come from how honest your sellers are. It is made or lost in what you fold into the number you display.
The default behavior of these systems runs the other way. Practitioners describing the real rules for picking a default offer list the product price, the shipping time, and quality indicators.
The product price on its own.
Which 4 numbers does a buyer call "the price"?
One product: laundry capsules. Four offers on one shared page, four numbers, four answers.
The numbers act on one another. After the discount, offer D costs €3.72 per capsule, so it also wins the column that C was winning a minute earlier.
There is no neutral way to present a price. You choose which of these questions your site answers, and whatever you do not show, the buyer will not work out on their own.
How do you put delivery into a price comparison?
This is the core of the problem, and the place where the choice is made by omission. If the list shows the offer price on its own, the buyer chooses badly and finds out in the cart.
Above, the gap between the tag and the bill is €19 on a price of €89, more than a fifth. If the list shows the total, you have to know the delivery cost before the buyer gives you an address: no address means no zone, and no zone means no rate.
We know of systems where the cart calculates shipping from a default zone, precisely because there is no address yet.
The regulatory direction is unambiguous. Before the order is placed, the buyer is to be told the amount payable including taxes, together with delivery costs, and where those costs cannot reasonably be calculated in advance, to be told they may arise.
So the rules do allow an "I do not know exactly" variant, provided you say so out loud. Silence is not that variant.
Hence the resolution I recommend: calculate the total from an assumption you name out loud, and show that assumption: "€113 with courier delivery inside the country." Three cheap additions. Where rates depend on parcel size, give a range ("delivery €15 to €29").
Where you use thresholds, show the distance to the threshold. With several methods, calculate the cheapest available one.
And one rule of arithmetic: round the forecast up. A buyer forgives a bill lower than the one promised, and calls a higher one a hidden cost.
Why does a unit price have to be a number?
A pack of 24 capsules at €96 and a single capsule at €4.80 cannot be compared until you work out €4.00 per capsule against €4.80. Without that, sorting by "cheapest first" pushes the single capsule to the top, because it is cheaper as a line item.
This is the only mechanism that turns packs of different sizes into one market. It also takes part of the multipack problem of offer matching off your hands.
For the operator, what matters more is where that number lives. The unit price is not a storefront field.
It is two catalog fields plus a table of reference units per category. The reference unit is attached to a type of goods rather than chosen once for the whole site: under the rules on how prices are indicated, some categories are counted per hundred grams, others per liter, wine per three-quarters of a liter, solid fuel per fifty kilograms.
So this is work in the category tree and in the attributes (the category tree and what you can enforce on content), and the seller fills the fields in.
Measure your coverage, because that is where the cost sits. Eight thousand offers in measurable categories, with the quantity field filled in on 40% of them, leaves you 4,800 offers with no unit price.
They are not comparable on your own site, and they drop out of comparison channels because those feeds require these attributes for goods sold by weight, volume, length, and area. Adding the requirement after launch comes back as a question about rules on a catalog that is already published (catalog rules).
We also know of systems that give you fields for the unit but explicitly do not calculate the unit price. What you buy there is somewhere to put the data.
Net or gross: which price does your storefront hold?
In a cart where both consumers and companies buy, one toggle is not enough. A toggle changes the view, while the problem is consistency across four surfaces: the list, the product page, the cart, and the document.
A business buyer who saw €1,000 and received a document for more than €1,200 does not report an interface glitch. They open a billing dispute, and in the implementations we know that is the most common cause of one.
The resolution has two levels. The first: which number you anchor.
One is typed in and the other calculated, and the one you type in decides where the rounding cent lands and what happens when a tax rate changes. Anchoring on the amount payable holds the price for the consumer and moves the net amount.
Anchoring on the net amount holds the seller's margin and moves the price on the shelf. Both are defensible, neither is the default, and the one indefensible option is leaving it unsettled.
The second level is reach. In solutions of this class, the offer price convention is a platform setting rather than a field on the offer, and the operator's duty is to tell sellers which one has been adopted.
Hence the warning of this article: the quiet irreversibility of presentation. The convention and the rounding method look cosmetic, and they are settled once.
Sixty thousand offers uploaded under one reading of them have no migration path to the other. We know of systems in which the rounding method is chosen when the platform is started up and cannot be changed once the first seller account exists.
On top of that comes arithmetic that stops being small at scale: tax rounded separately on every line gives a different total from tax on the order total. Three cents across 40,000 orders in a year is €1,200 that no report will ever reconcile.
What matters here is only this: the duty to show the amount payable covers sales to consumers, while showing net amounts between businesses is a practice and not a requirement.
Why do the amount shown and the amount charged differ?
Two architectures, two problems. Either the seller types a price separately in each currency: there is no conversion and no drift, but an offer with no price in the second currency is invisible in that channel.
Or you convert at a rate. Coverage is then complete, and the drift is built in.
Where the drift comes from. Amounts live in these systems in the smallest unit of the currency, and the number of decimal places depends on the currency: some currencies have no decimal part at all, and some settle payouts only in whole hundreds of units.
The rate shown on the storefront is usually a snapshot of the day. The rate at which money changes currency belongs to the payment provider and applies at the provider's moment.
The amount presented and the amount settled are therefore two numbers by definition.
Settle three things. The binding amount is the one in the currency the buyer pays in, fixed and frozen when the order is placed.
Everything shown before that is information and has to be labeled as such. Round once, at the end, because a sum of rounded numbers is not the rounded sum.
And do not round the rate: 4.2987 shortened to 4.30 moves every amount by 0.03%, which on €4 million of turnover in that currency is €1,200 of error in one direction. The drift at the level of cents is small (5,000 orders at two cents each is 100 units of currency a month), but there is nowhere to book it, so it costs hours of reconciliation.
When is a "from" price misleading?
A product page with six variants and four offers holds 24 price combinations. "From €199" comes from one of them, and the buyer who came for the popular variant pays €349.
That is 75% more.
The rule is simple, and a machine can check it. You may show the lowest price when it belongs to a combination that can be bought at that moment (stock above zero, seller active), when a range or a count of variants stands next to it ("from €199 to €349, 6 variants"), and when the product page opens on the same variant the number on the list came from.
The third condition breaks most often and is the hardest to detect, because the list and the product page are two different queries against two different indexes. The direction is written into the structured data standards search engines read: where one product has many offers, you publish the lowest price, the highest price, and the number of offers together.
Not the lowest one on its own (SEO on pages with many offers).
What does price presentation change about the rest of your catalog?
1. Comparability of offers for the same product is the only reason a shared page makes sense
Every simplification in how you show the price takes from that page the value you pay for in hours of offer matching: no delivery in the number, no unit price, a "from" with no range.
2. The commission base is a decision separate from what you display
A €1,000 cart at a 12% commission gives you €120 and the seller €880, whatever number sits on the screen. Whether delivery went into the commission base, though, changes your revenue.
2. Presenting the price is a catalog requirement
The unit of measure, the quantity in the pack, and the tax convention are fields filled in on every offer. They belong to your data quality rules.
How do you check price presentation on your own storefront?
- Show us a list where the amount with delivery stands next to the price. Where does that delivery come from with no address, and what about rates that depend on parcel size?
- Where do the quantity and the unit of measure live, who fills them in, and does the platform calculate the unit price, or does it only store the fields?
- Is the offer price net or gross: a platform setting, a field on the offer, or something that depends on the channel? Where is it switched, and what happens to the offers already uploaded?
- Which amount is binding when there are two currencies, and when do you freeze the rate? Show us an order with the amount shown and the amount charged.
- What is the rounding method, who chooses it, and can it be changed after the first order?
- Show us a product page with six variants and four offers. Where does the "from" come from, and can that version be bought right now?
No demonstrable answer to question 1 or 3 means you will be building comparability yourselves.
Which mistakes do operators make about showing prices?
1. The price on the list, the total in the cart
The cheapest item on the list turns out to be the most expensive on the bill. Consequence: the buyer stops trusting your numbers, and you see it as an abandoned cart rather than as a presentation error.
2. The unit price stored as a text field
The seller types "about €4 per unit" instead of a number and a unit. Consequence: it does not sort, it does not filter, and it does not go out to comparison channels.
3. A net/gross toggle instead of a convention
The storefront gets a button, and the data schema gets no decision. Consequence: four surfaces show three numbers, and a dispute with a business customer is settled over email.
4. Rounding done in every layer separately
The storefront rounds the line, the cart adds up the rounded lines, and the document calculates from the source amounts. Consequence: three totals for one order, and a monthly job nobody planned for.
5. A "from" price calculated from a combination nobody can buy
A variant with no stock or from a suspended seller still sets the number on the list. Consequence: a price promise repeated across thousands of pages.
What do you still have to settle about your own prices?
This chapter does not touch price history, the reference price, the crossed-out price, or the message about a reduction. That is the whole core of price history and discount messages, and required reading if you display any percentage at all.
It also leaves these to their own chapters:
- who sets the price and whether you require parity, and discount codes, in the chapters on pricing and promotions
- payment splitting, in "How Marketplace Split Payments Work and Who Pays the Fees?"
- tax, in agent or principal for VAT and "Marketplace Invoicing: Who Issues Which Invoice, and When?"
- the choice of a default offer, in the rule that picks the winning offer
- the cost of delivery in the cart, in a cart with several sellers
- structured data, in SEO on pages with many offers
Three things are worth confirming with a lawyer, because what your team needs from them is a table:
- which categories require a unit price, and in which reference unit
- what has to be visible as the amount payable before the order is placed, and how to describe a cost that cannot be calculated in advance
- whether you may show business buyers amounts without tax only
The families of regulation worth naming, with no attempt to settle which of them apply to you:
- the rules on price indication, in the part about the total price and the unit price
- the rules on consumer rights in distance contracts, in the part about information given before the order is placed
- the rules on unfair commercial practices, wherever the way costs are revealed could mislead
Our own claim is narrower and independent of those answers: a platform on which the number from the list is not the number the buyer pays does not offer a comparison of offers.
Summary: What makes two offers comparable?
Showing the same number for both. That sounds obvious until you count how many numbers one word hides: the goods, the goods with delivery, the price per unit, and the smallest price in a range.
Each is honest, and each ranks the sellers differently, so the choice of which to display is the choice of who looks cheapest. Settle it in the data rather than in the template – one convention for net and gross, a unit price held as a number with its unit, a currency that says which amount will be charged – and the storefront stops being the place where prices are invented.
Put two offers of one product side by side and write down every number a buyer would call the price. Building a marketplace where the amount on the list is the amount in the cart?
Frequently asked questions on marketplace pricing display
Which price should a marketplace show on a listing?
A marketplace should show on a listing the price the buyer will pay, as far as it can be known at that point. Showing the goods alone puts the seller with expensive delivery at the top of a sort by price, and the buyer discovers it in the cart. If delivery cannot be known yet, say so on the same line rather than later.
How should a unit price be stored?
A unit price should be stored as a number with a unit of measure, on the offer, and never as free text. It is the only bridge between a pack of twenty-four and a single can, so it has to be sortable and filterable. A seller typing "about €4 per unit" gives you a string nothing can compare.
Should a marketplace hold prices net or gross?
A marketplace should hold prices in one convention for the whole catalog and convert on the way out. A toggle in the storefront leaves the data ambiguous, so the same offer means two things depending on who reads it, and the ambiguity ends up in the commission and in every report.
Ready to build?
If you want to check whether the number you show on the list is the same number the buyer will pay, let's talk.