Base rule and layers
Every ticket type starts from a base price, with optional layers by day of week, season or time of day. If two layers overlap, the more specific one wins.
Pricing & Taxes
One final price. A dozen reasons behind it.
Season, time of day, occupancy, lead time, compound taxes: every layer resolves at query time, in the same order, always. There is never a separate "estimated" price from the one actually charged.
- Cost → net → retail Each one derives from the others automatically; margin never gets lost
- 2 Dynamic pricing triggers: how full the slot is, and how far ahead the booking is
- Compound Taxes can chain together, each one calculated on the result of the last
Four pieces. One final price.
Each layer answers a different question, and all of them combine into the same calculation.
Price exception
For one exact date and time, like a special event, without touching the regular configuration for the rest of the calendar.
Dynamic pricing
Adjusts the price automatically based on how full the slot is or how close the date is, by percentage or fixed amount, up or down.
Taxes per category
Each tax defines its own base (retail, net or margin), its mode (included, additive or internal), and whether it compounds on the one before it.
How it resolves
How a price gets calculated, step by step
Five steps, in this exact order, every single time someone requests a price.
- 1
Price exception
Is there an exception configured for this exact date and time? It beats any recurring rule, no matter how specific that rule is.
- 2
The most specific base rule
If there's no exception, the best-matching recurring rule applies: time of day outweighs season, which outweighs the general base rule.
- 3
Dynamic adjustment
The highest-priority active dynamic pricing rule that triggers for that moment gets evaluated, and its adjustment applies to the retail price.
- 4
Taxes in order
Each assigned tax is calculated on its own base, in the configured order. One marked as compounding is calculated on the previous tax's result, not on the original price.
- 5
Final total
Whichever taxes actually affect what the customer pays get added up and rounded to two decimals. That's exactly what checkout charges.
The API, as it is
The same breakdown checkout sees
Cost, net, retail price, the dynamic rule applied if there was one, and every tax listed separately with its own base and amount. Never a total with no explanation of where it came from.
GET /api/v1/products/observation-deck/calendar
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
{
"currency": "EUR",
"cost": 18,
"net": 28.1,
"base_retail": 40,
"retail": 44,
"applied_dynamic_rule": {
"trigger_type": "occupancy_threshold",
"adjustment_type": "percentage",
"adjustment_value": 10
},
"taxes": [
{
"name": "VAT",
"basis": "retail",
"application_mode": "additive",
"rate_percentage": 21,
"amount": 9.24
}
],
"customer_total": 53.24
}200 Price resolved
The detail almost nobody offers
VAT can be charged on the margin, not the price
For resellers in the European Union, the margin scheme (TOMS) requires calculating tax on the difference between what the customer pays and what the supplier gets paid, not on the full retail price. Any tax category can define its base as retail, net or margin: this calculation isn't a special case in the code, it's one of the three normal options.
Frequently asked questions
The exception for that exact date and time always wins over any recurring rule, no matter how specific that rule is.
Same as with availability: the more specific one wins. A rule scoped to time of day outweighs one scoped only to season, which outweighs the general base rule.
Yes, and each one can have its own base (retail, net or margin) and mode (included, additive or internal), in an explicit order. One marked as compounding is calculated on the previous one's result, not on the original price.
No. Each rule defines its own adjustment type (percentage or fixed amount) and a value that can be negative, so the same mechanism covers both a last-minute surcharge and an early-booking discount.
Depends on how each tax is configured. An "included" one is already part of the shown price; an "additive" one gets added separately at checkout; an "internal" one is never charged to the customer, only recorded for accounting. The full breakdown is exposed in the API, not just the total.
More bookings. More channels. The same calm.
Tiqory keeps availability, pricing, payments and access working together as your operation grows. Tell us where you are headed; we’ll show you how to get there without starting over.