Skip to main content

Open in TWICE Admin

Catalog → Price Tables
A price table is a rate card. One object holds the prices for a selling mode, and any number of listings can point at it — so re-pricing a category is one edit rather than forty. This guide builds a shared table and tiers it by duration. If you only need to price a single listing, price a listing does that from the listing’s own Pricing tab and is the shorter road.

​
Prerequisites

Required permission: catalog:price_table. Linked listings are a separate gate — catalog:price_table_linked_listings — so a role can be able to edit prices without being able to see which listings they affect.
A shared table is a shared consequence. The reason to build one is that editing it re-prices every listing linked to it at once. That is the feature, and it is also the trap: the Linked listings tab is the only thing standing between a routine price edit and forty listings changing.Check that tab before you edit an existing table, not after.

​
The walkthrough

1

Create the table — it exists immediately

Go to Catalog → Price Tables and click Create Table.There is no dialog. TWICE creates the table straight away, names it Unnamed, and opens it. The steps below are editing a table that already exists.
2

Name it

On the General tab, Details holds two fields. Fill in the first.Name is how you will recognise it in the picker when you attach it to a listing. It is internal — customers never see it — so name it after what it prices (“Standard bike rates”), not after a listing.
3

Decide whether it is dated

Validity is the second field, and it is the date window. Leave it empty and the table is always in play. Set it and the table’s rows only become candidates inside that window.Leave Validity empty on this table. Only price tables without a validity period can be used as a listing’s default price table — a dated table cannot be attached as a listing’s default, and it does not override one.Dated tables layer over a default rather than replacing it, and the troubleshooting below covers what that does and does not let you charge.
4

Turn on the selling modes you actually use

The Prices card — set the prices and purchase types for the table — holds three independent sections: Purchase price, Booking price and Subscription.One table can carry all three. Turn off the ones you do not sell; the rows stay but the editing surface stops offering them.
5

Choose fixed or rate-based booking prices

Booking prices come in two shapes, and the choice decides what the customer does on the storefront.
  • Fixed price for duration — fixed prices for specified periods — e.g. 1 day or 3 hours. The customer picks one of your rows. Add them with Add fixed duration price.
  • Rate-based — the customer picks any start and end, and the engine prices the span from your rows. Add them with Add rate-based price.
Most rate cards are rate-based, because that is what makes tiering do any work. A fixed-price table with a day row and a week row offers exactly two options; a rate-based one covers everything in between.
6

Set the duration tiers

This is the actual rate card. Add one row per tier, each with a Period (a number and a unit) and a Base price:The tiering is what makes a week cheaper per day than a day is. You do not configure a discount — you price the longer block lower per unit, and the engine does the rest.Add rows at the durations customers actually book. A gap between 1 day and 1 week means every mid-length rental is priced out of day-rows. Rate-based pricing works through what that means for the durations between your tiers.
7

Check how the engine will read those tiers

Check one sample duration against the rows you added.For each part of the booking the engine takes the row with the longest duration that still fits, breaks ties on the lowest price, and fills the remainder with shorter rows and the Additional price rule. A 9-day rental off the table above resolves as a week plus two days, not as nine day-rows.It does not shop for the cheapest total, so pricing the tier is your job: a week row priced above seven day-rows is still what a seven-day booking gets. On the Starting at basis it does compare compositions (Price resolution).
8

Decide how a partial period is charged

Each row carries a pricing model, and it is the setting most worth getting right.Starting at pricing — charge for every calendar period the booking touches: a 23:00 pickup and a 01:00 return counts as two days. With it off, prices are charged by booked duration — a day is 24 hours from pickup.The unit dropdown names it per row: Day (Elapsed) versus Day (Started).This is a revenue decision, not a display one — it is the difference between a ski hire and a plant hire. Price a listing works through the reasoning; the choice you make there applies here.Sub-hour rows are always charged by duration, whatever the table’s model.
9

Attach the table to listings

A table with no listings pointing at it prices nothing. Attaching happens from the listing, not from the table: open a listing’s Pricing tab and pick this table.The picker only offers shared tables with no validity period, which is the same constraint from step 2 seen from the other end.The table’s Linked listings tab — listings using this price table — then lists everything attached, with Unlink on each row. That tab is your blast radius.

​
How do I know it worked?

The table appears in Catalog → Price Tables with its Name, its Validity, and a Linked listings count. That count going up is the confirmation that attaching worked. The check that proves the tiering works is a real quote. Open one of the linked listings on the storefront and price a duration that should land on a longer tier — a 7-day rental on the table above should come out at €180, not 7 × €40. If it comes out as the sum of day-rows, the week row is not being selected, and the troubleshooting below covers why.

​
Troubleshooting / common pitfalls

Working as designed, and the reason shared tables exist. Every linked listing re-prices together.What to do: open Linked listings before editing. If one listing needs to move independently of the others, give it its own table rather than editing the shared one — the shared table is the wrong instrument for a one-listing change.
Cause: no longer row is eligible for the booking. On the default Elapsed duration basis the engine takes the longest row that fits, whatever it costs — so if a week row exists and fits, price is not why it lost. One of these is true instead:
  • It is disabled.
  • Its table is not active for those dates.
  • Its weekday, time of day or date restrictions exclude the booking.
What to do: check the week row is enabled, that its table has no validity period excluding the dates, and that its restrictions are empty. Price only decides between two rows of the same duration.On the Starting at basis, price does decide across durations — there the engine compares one week against the cheaper composition of shorter rows, and a week priced at or above seven started days genuinely loses. See Price resolution.
Cause: a dated table does not override the default — its rows compete in the same pool, and between two rows of the same duration the cheaper one wins.What to do: a cheaper promotional row works with no further effort. A higher one does not, and needs the competing default row removed or date-restricted for that window so nothing cheaper covers it. The mechanism is set out in Price resolution.
Working as designed. Only tables without a validity period can be a listing’s default, and the picker filters to those.What to do: keep an undated table as the baseline and let dated tables layer over it. A dated table is an overlay, never a substitute for having a default.
Cause: rows carry optional weekday, time of day and date restrictions, and a segment matching none of them falls through.What to do: give at least one row a fallback price so any uncovered segment has something to resolve against. Where several rows offer one, the cheapest applicable wins.
Not available. A table is scoped by validity period and nothing else. There is no per-location or per-channel price.What to do: two locations that must charge differently need separate listings with separate tables — which also means separate stock rules and separate publishing. Worth being sure the difference justifies that.
Not on a price table. There is no per-customer-tag pricing in the model.What to do: use a discount code restricted to the listings or collections in question. A staff-only code covers the contract-rate case.

Price a listing

The single-listing road, and the Elapsed versus Started reasoning in full.

Price tables

The model behind tables, rows, and resolution.

Price Tables view

The view reference, field by field.

Create a discount code

Taking money off a price rather than changing it.