Different cancellation policies between availability and rate check in B2B Reservas

Different cancellation policies between availability and rate check in B2B Reservas

When searching for hotels through the B2B Reservas supplier, the cancellation policy displayed during the availability stage may differ from the policy returned later during the rate check or booking confirmation.

This is an expected behavior and occurs because each stage of the integration may use a different source to determine the applicable cancellation policy.

How the cancellation policy works

Availability

During the availability stage, through the OTA_HotelAvailRS response, the supplier may return the generic cancellation policy configured for the hotel.

For example:

<CancelPenalties>    <CancelPenalty>        <Deadline            OffsetTimeUnit="Hour"            OffsetUnitMultiplier="24"            OffsetDropTime="BeforeArrival" />    </CancelPenalty> </CancelPenalties>

In this example, the information indicates that cancellation is allowed up to 24 hours before arrival.

However, it is important to consider that this policy may represent only the hotel's general rule and may not necessarily correspond to the specific conditions of the selected rate.

Rate check

During the rate check stage, through the OTA_RoomRateInfoRS response, the supplier checks the specific conditions associated with the selected rate.

If the rate has its own cancellation policy, this configuration takes precedence over the generic policy previously displayed during availability.

For example, the response may return an absolute date:

<CancelPenalties>    <CancelPenalty NoCancelInd="false">        <Deadline AbsoluteDeadline="2026-08-30T14:00:00" />    </CancelPenalty> </CancelPenalties>

In this scenario, the rate may have a specific rule such as:

Cancellation allowed up to 480 hours, or 20 days, before check-in, with a 100% penalty applied after this deadline.

The AbsoluteDeadline is calculated according to this configuration and represents the actual cancellation deadline based on the policy configured for that rate.

Which policy should be considered?

When there is a difference between the policy displayed during availability and the policy returned during the rate check, the policy returned during the rate check should be considered.

This happens because:

Availability: may display the generic cancellation policy configured for the hotel.

Rate check: displays the specific cancellation policy configured for the selected rate.

Booking: uses the specific cancellation policy of the rate that will effectively govern the booking conditions.

Therefore, if a rate has its own cancellation rule, it will take precedence over the generic condition previously displayed during availability.

Practical example

Consider a stay with:

Check-in: September 19, 2026
Specific rate rule: cancellation allowed up to 480 hours before arrival
Check-in reference time: 2:00 PM

Since 480 hours correspond to 20 days, the cancellation deadline will be calculated as:

August 30, 2026 at 2:00 PM

Therefore, if the rate check is performed after this date, the cancellation deadline may already be expired.

This does not necessarily mean that there is an error in the integration calculation. The behavior may be related to the specific cancellation policy configured for that rate.

What if the deadline has already expired?

It is also possible to encounter scenarios where the XML returns:

NoCancelInd="false"

while the AbsoluteDeadline is already in the past.

The NoCancelInd="false" attribute indicates that the rate was not explicitly configured as non-refundable or non-cancellable.

However, if the deadline defined by the specific rate policy has already expired at the time of the rate check, the applicable cancellation penalties may already be in effect.

For this reason, the analysis should not consider only the NoCancelInd attribute. The deadline returned in Deadline and the other penalty conditions provided by the supplier should also be evaluated.

Why does the policy change between stages?

The change does not necessarily represent an incorrect recalculation of the cancellation policy.

In B2B Reservas, the availability stage may use the hotel's default cancellation configuration, while the rate check stage retrieves and applies the specific rules configured for the selected rate.

Therefore, when a specific cancellation policy exists for a rate, this rule will be applied from the rate check stage onward and will also be reflected in the booking.

Guidance for analysis and support

When identifying a difference between the cancellation policy returned during availability and the one returned during the rate check, it is recommended to verify:

1. Whether availability is displaying the hotel's generic cancellation policy.
2. Whether the selected rate has its own cancellation policy.
3. The value returned in AbsoluteDeadline, when applicable.
4. The cancellation advance period configured for the rate.
5. The penalties applicable after the cancellation deadline.
6. The cancellation policy returned during the rate check and later reflected in the booking.

For presentation to the user and application of cancellation conditions, the policy returned during the rate check and reflected in the booking should be considered the valid policy for that rate.

Summary

In the B2B Reservas integration, differences in cancellation policies between availability and rate check may occur because different rules are applied at each stage.

Availability may display the hotel's generic cancellation policy, while the rate check displays the specific cancellation policy configured for the selected rate.

When a specific rule exists for the rate, it will take precedence and should be considered for booking confirmation and any future cancellation.