Platform module
Pricing and markup engine
Net rate to final price, by rule, versioned and auditable.
How does a travel pricing engine calculate a selling price?
A pricing engine turns a supplier net rate into a selling price by applying ordered rules: markup, commission, tax, fee, then discount. TravelCore computes in minor units to avoid floating-point drift, breaks ties on rule identity so array order can never move a price, and can replay any past month against proposed rules before you publish them.
Every travel business makes its money in the gap between a supplier's net rate and the price a customer pays. In most systems that gap is expressed in code, which means a commercial decision needs an engineering release and nobody can reconstruct why a price was what it was six months ago.
The pricing engine turns that gap into data. A rule matches on dimensions (market, currency, channel, product, supplier, property, agent, customer segment, season, stay dates, booking value) and applies an operation (percentage markup, fixed markup, tiered markup, commission, discount, tax, service fee). Rules are ordered, versioned, and effective-dated.
Crucially, the computed breakdown is stored on the booking, not recomputed on read. A commission dispute three months later is settled by looking at what the engine decided at the time, not by re-running today's rules against yesterday's booking.
The engine runs on this page, from the same modules the test suite imports and covered by 30 tests. Those tests include the unglamorous ones that decide whether the arithmetic is right at all: money held in minor units so five lines do not accumulate drift, rounding away from zero so a customer is never undercharged a cent, and the kind ordering that determines whether an agent's commission is taken on the net rate or on the selling price.
The hard part
Reproducibility
A price must be explainable after the fact. Every booking carries the rule ids and versions that produced it, so any line of the breakdown can be traced to the exact rule that created it.
Capabilities
- Rule dimensions: market, currency, channel, product, supplier, property, agent, segment, season, dates, value
- Percentage, fixed, tiered and stepped markup
- Commission and sub-agent commission tiers
- Tax and service-fee rules per jurisdiction
- Promo codes and discounts with stacking rules
- Effective dating and rule versioning
- Full breakdown stored on the booking, not recomputed
- Dry-run preview: see what a rule change would have done to last month's bookings
Worked example
A price you can explain six months later
Every line references the rule and version that produced it, and the whole breakdown is stored on the booking rather than recomputed on read.
Stored on the booking, not recomputed
Run it yourself
Change a rule and see what it would have done
The engine below is the same code the test suite imports. Every line names the rule and version that produced it, and the dry run re-prices a month of bookings against a proposed change — the question a commercial team asks before every rule edit.
Price build-upruleset a6bae250
Gulf market uplift (PR-114 v3) applied 15% of the running subtotal because market is one of AE, SA, QA, KW and channel is b2c.
UAE VAT (TX-300 v1) applied 5% of the running subtotal because market is AE.
Booking service fee (SF-400 v1) applied a flat 40 because channel is one of b2c, api.
SUMMER26 promotion (DC-500 v1) applied 2% of the running subtotal because promoCode is SUMMER26.
Customer pays
3,731.25 AED
Gross margin
391.85 AED
Owed to agent
0.00 AED
Dry run
What would this change have done to last month?
The question a commercial team asks before every rule change, and that almost no pricing system can answer. Move the Gulf uplift and the engine re-prices the whole fixture month against both rule sets.
Bookings affected
0 of 6
Revenue delta
+0
Margin delta
+0
Deltas mix currencies, because the fixture month does. A production dry run converts at the rate stamped on each booking rather than at today's — which is another thing a stored breakdown makes possible and a recomputed one does not.
Related
The rest of the core
Booking engine
One flow from search to voucher, for every product type.
Hotel mapping and normalisation
The same property from many suppliers, resolved to one object.
Supplier control center
Onboarding, credentials, mapping runs and honest health data.