New Features

Attach booking confirmation to flight notifications

Airlines can now attach a booking confirmation document to flight notification emails sent from both the Flight Notifications and Flight Series screens, in addition to the existing manual notification text, using a new "Attach confirmation" checkbox.

The correct confirmation template is selected automatically based on booking ownership: the direct-customer template for direct bookings and the agency template for agency bookings. This ensures that the pricing shown to each recipient remains accurate.

Payment completed via eMerchantPay link is recorded in PNR log

Payments completed through third-party payment links from the CRS Payment screen, such as eMerchantPay, are now recorded in the PNR History/Log.

Previously, these payments were processed successfully and appeared in the booking invoice and the Receipts report, but no corresponding entry was written to the PNR log, leaving agents and support teams without a complete audit trail.

The PNR log now records the payment transaction once it is completed, and failed payment attempts are also logged. This solution applies to all payment service providers that use this link-based payment flow.

Improvements to Existing Features

Alerts before changes to flights enabled for GDS distribution

The CRS now displays alerts before users perform actions on GDS-enabled flights that could silently cause GDS reservations to be cancelled.

Warnings are displayed when deactivating a flight from GDS (the flight will be marked as "not operating" on the GDS side), switching to a service load whose aircraft has no IATA identifier, disabling a class from GDS, or changing destinations on a GDS-enabled flight.

The alerts are available on both the Flight and Flight Series screens, including for bulk actions such as Set GDS Status, Update Class, Service Loads, and Update Destinations.

Users can proceed with or cancel the action. If they cancel, the previous value is restored.

Accommodation assignment in confirmBooking API

The confirmBooking API now accepts an optional accommodations parameter, allowing API integrations to assign accommodation selections during the booking flow.

Each entry specifies the accommodation (by name or code, matching the values returned by getRoutes) and the airport to which it applies. The accommodation is applied as the "From" accommodation on flights departing from that airport and as the "To" accommodation on flights arriving at it, mirroring the existing IBE logic for one-way, round-trip, and multi-segment itineraries.

The parameter is entirely optional, so existing integrations that do not include it are unaffected. Additionally, no accommodation-mandatory validations are enforced at the API level, avoiding any impact on OTA bookings.

Bug Fixes

API login checks for inactive customers (webLogin / recoverPassword)

Fixed an issue where the v5 webLogin API authenticated customers whose records were marked inactive in the CRS, creating a session and returning a redirect URL.

The recoverPassword API had the same issue and sent password recovery emails to inactive customers.

Both endpoints now check the customer's active status and return an error if the customer is inactive, consistent with the legacy IBE login behavior. Active customers are unaffected.

Incorrect passenger type in MMB for seat-only bookings

Fixed an issue where, when repaying a seat-only booking through Manage My Booking (MMB) after the ticket had been cancelled and repriced in the CRS, the passenger type was displayed as "Child" with no option to change it.

The passenger page previously generated passenger forms based on the flight search, which is unavailable in the MMB flow. This resulted in incorrect passenger types and caused the page to freeze for bookings with multiple passengers.

The page now uses passenger counts from the retrieved booking when no search is available, rendering one form per passenger with the correct passenger type and title options. Regular search-driven bookings are unaffected.

VAT on tax items missing from IBE auto-sent booking confirmation (new fare structure)

Fixed an issue where booking confirmations sent automatically by the IBE did not display VAT applied to tax items, even though the same confirmation generated from the CRS displayed it correctly.

The VAT field in IBE-sent confirmations now correctly includes VAT on tax items where applicable, matching the CRS output for the same confirmation template.

IBE calendar display issues when switching trip type

Fixed calendar display issues in the IBE when switching between round-trip and one-way trips.

Previously, switching from round-trip to one-way left the calendar empty, while switching back to round-trip displayed only about one month of future dates.

The calendar now displays correctly after any trip type change, allowing customers to continue browsing and selecting dates without reloading the page.

Rebook displays baggage selection for both segments instead of only the changed segment

Fixed an issue where, after rebooking only one segment of a round-trip booking, the baggage selection step displayed baggage options for both the outbound and return segments.

This allowed passengers to purchase baggage again for the unchanged segment, potentially resulting in duplicate baggage on the same flight.

The baggage step now displays options only for the segment changed during the rebooking process. The unchanged segment retains its existing baggage, which is no longer available for selection.

getAncillaries and getAirlineAncillaries - Website and CRS behavior

Fixed an issue where the getAncillaries and getAirlineAncillaries APIs returned ancillaries configured to be displayed only in the CRS.

The "Shown on Website" filter was previously applied only to web or act-as-web requests, meaning other credentials could also retrieve CRS-only items.

Both APIs now return only ancillaries marked as "Shown on Website", regardless of the credentials used for the request. Ancillary display in the CRS remains unchanged.

Issue with class parameter in getAirlineAncillary

Fixed an issue where the class parameter in the getAirlineAncillary API read only the first character of the class code.

Airlines using two- or three-character class codes received a "Flight not found in system" error, even though the same class worked in getDeepLink.

The API now reads the full class code provided in the request, ensuring that ancillaries are returned correctly for class codes of any supported length.