Pricing a Booking Across Rate Boundaries

01 / 06

The booking start time was the wrong abstraction

The venue had an off-peak rate and a later, higher rate. A calculation that selected one rate from the booking start time could look reasonable for most bookings while getting the boundary case wrong. A session beginning at 13:30 and ending at 14:30 occupied both bands. Charging the whole hour at the first rate did not represent the service the customer had reserved.

The fix started with the business rule, not the price label. This venue wanted occupied time priced in segments. Other venues still used a session-start policy. Replacing a global pricing function with the new behavior would have silently changed their agreements, so I made the policy explicit at the venue boundary.

02 / 06

Split first, accumulate second, round last

The calculation partitions the booking at applicable rate boundaries, prices each overlap for its duration, and adds the contributions. Currency rounding happens once after the accumulation. Rounding each intermediate segment independently can make a subdivided interval disagree with the same interval priced as a whole.

In the recorded example, 30 minutes at NZD 25 per hour contributes NZD 12.50. The next 30 minutes at NZD 50 contributes NZD 25.00. The verified total is NZD 37.50. A booking wholly inside the second band, from 14:00 to 15:00, remains NZD 50.00. These paired cases distinguish the new boundary behavior from a general price change.

segments = splitAtRateBoundaries(booking.start, booking.end)
amount = sum(segment.hours * segment.hourlyRate for segment in segments)
total = roundToCurrency(amount)
audit.rateRuleIds = unique(segments.rateRuleIds)

03 / 06

The preview and the order need one authority

A correct server calculation is not enough if the browser previews a different algorithm. I reused the segmented calculation for quote preview, order creation and the daily pricing view. The server recomputes the amount when the booking is created. A displayed number is an explanation to the customer, not authority to charge an arbitrary client-supplied total.

The UI also stopped advertising a low starting price before the customer had chosen a time and bay. Once that choice was complete, it displayed the server-verified total and explained that a session spanning rate windows uses the corresponding rate for each part. This connected the pricing model to the decision the person was actually making.

04 / 06

Preserve the reasons behind the amount

The audit metadata records all rate-rule identifiers used by a multi-band booking. Keeping only the first rule would conceal why the final amount differs from the starting rate. This matters when support needs to explain a receipt without reconstructing a past configuration from today’s settings.

The new venue selected the time-segment policy. Existing venues retained their session-start behavior. That separation kept a local business requirement from becoming an accidental platform default. The same principle applies to booking windows, time increments, membership allowances and tax presentation.

05 / 06

Test the boundary and the customer path

The August 15 record reports 46 booking-rule checks and 297 application acceptance checks passing, alongside TypeScript and relevant lint checks. New regressions covered the crossing interval and an interval wholly within the later band. Those totals describe the recorded revision, not a permanent guarantee for every later release.

The test deployment was also checked in desktop and 390-pixel mobile browsers. Selecting the one-hour session at 13:30 showed NZD 37.50, with no horizontal overflow or console errors in that pass. That task did not publish the change to production. Its evidence is a completed implementation and test release, and should be described at that scope.

06 / 06

Treat a quote as a reproducible decision

The durable improvement was a single explanation of the amount: selected venue policy, occupied interval, applicable rules and one final currency result. The UI, creation path and audit trail could all point back to that explanation. A pricing bug became much easier to reason about once the system stopped treating a booking as one start-time label.