How it works
Two engines, one switch
Rate-based resolution is not one algorithm. Which one runs depends on the time basis of your rows, set by the Starting at pricing checkbox on the table:
The rest of this page describes Elapsed, the default and the one most rentals use. Starting at is covered in Starting at pricing.
The walk
On Elapsed, the engine starts at the pickup instant and moves forward:1
Find the rows that fit
A row is eligible for the remaining time only if its full length still fits. A 1-week row is not eligible for a 6-day booking — not at any price.
2
Take the longest one
Among the rows that fit, the longest wins. Price is compared only when two rows are the same length.
3
Advance and repeat
The clock moves forward by that row’s length, and the search runs again on what is left.
4
Round up the remainder
When the time left is shorter than every row, the engine bills one unit of your shortest row and stops.
The rules that decide every price
A row must fit before it can win
A row must fit before it can win
Eligibility comes before price. A row whose length exceeds the time remaining is not a candidate, so the tier you designed for long rentals does nothing until the booking is long enough to contain it.
Price only breaks ties between rows of the same length
Price only breaks ties between rows of the same length
The engine does not compare a week against seven days and pick the cheaper total. It picks the week because it is longer. An over-priced long row is not priced out — it is preferred.Tiering produces a discount because you priced the longer block lower, not because the engine shops for the cheapest total.
The first block bills the base price, later blocks bill the additional price
The first block bills the base price, later blocks bill the additional price
The first block the walk takes uses Base price. Every block after that uses that row’s Additional price, falling back to the base price when you leave it empty.Each row has its own additional price, and which one applies depends on where the walk lands. On a table with 4-hour and 8-hour rows, hours 9–16 are priced by the 8-hour row’s additional price.
Any remainder rounds up to your shortest row
Any remainder rounds up to your shortest row
A booking that ends 10 minutes into a gap no row can fill is billed a full unit of the shortest row on the table. If your shortest row is 2 hours, every remainder costs 2 hours.
Restrictions decide eligibility before anything else
Restrictions decide eligibility before anything else
A row’s weekday, time of day and date range restrictions are checked first. A restricted row is not a candidate for a segment it does not cover, however long or cheap it is. When a stretch of the booking matches no row at all, the engine uses a fallback price if any row offers one.
Usage
What happens between two tiers
Take a listing with four rows and no additional prices set:
A 19-hour booking does not cost €60. The day row needs a full 24 hours to be eligible, so it never enters the running:
19 hours costs €140. A full day costs €60.
This is the single most common surprise in rate-based pricing, and the cause is always the same: the additional prices are empty, so they fall back to the base price. Set them and the gap behaves:
With 8-hour additional €6, 4-hour additional €3, 2-hour additional €2:
What happens at a tier boundary
The boundary is exact, and it is not symmetrical. Take a table with a 1-week row at €300, a day row at €60, and the rows above:
A booking 30 minutes shorter costs €79 more. Customers see this on the storefront.
The fix is not a pricing setting. It is booking limits: set a duration increment so 6 days 23 hours 30 minutes is not offerable in the first place. The storefront only presents increment-aligned end times.
What you can and cannot express
Techniques
Put a row where the price should change
Put a row where the price should change
Period is a free number and a unit, not a fixed list. If your price should change at six days, add a 6 days row. Under Elapsed it becomes eligible at exactly six days and wins as the longest fit.This is the answer to most “the price is wrong between X and Y” problems. Rows are cheap; the gaps between them are what cost you.
Constrain durations instead of pricing every one of them
Constrain durations instead of pricing every one of them
Rate-based plus a duration increment gives you a finite, checkable price ladder without listing fixed prices. Set the increment to your shortest tier, or a divisor of it, and the durations that produce odd results stop being bookable.This is what makes rate-based practical for a catalog where fixed prices would mean thousands of rows.
Give at least one row a fallback price
Give at least one row a fallback price
If you use weekday or time-of-day restrictions, some stretch of some booking will eventually match no row. A fallback price on at least one row gives that stretch something to resolve against. Where several rows offer one, the cheapest applicable wins.
Checking your table
Price a real booking on the storefront rather than reading the rows. Three durations catch nearly everything:- One just below a tier — 23 hours on a day/week table. Shows whether your additional prices are set.
- One just above a tier — 25 hours. Shows what the remainder rounds up to.
- One in the middle of your widest gap — 19 hours on a 8h/24h table. Shows the worst case a customer can hit.
Related
Price Tables
The full field reference and price resolution across tables
Build a price table
Setting one up step by step
Price a listing
Choosing a pricing shape for one listing
Booking limits
Duration increments, minimums and maximums