New Features
Bank payment for Ozow Payment Gateway
Added support for bank-specific payment routing in the Ozow payment gateway by introducing a new SelectedBankId parameter driven by the terminal's VAR5 configuration field. When VAR5 is left empty, existing Ozow payment behavior remains unchanged; when populated, the configured bank identifier is included in the request and factored into the hash calculation used to validate the transaction. This allows an airline to configure multiple Ozow terminals, each tied to a specific bank or payment option, such as a dedicated credit card terminal, without any changes to the core payment flow.
Payment link via email for Pesapal Payment Gateway
Added an email delivery option for Pesapal payments, giving users a choice between the existing hosted payment link and having the payment request emailed directly to a recipient.
Hosted Payment Page / iframe Integration for BAC Payment Gateway
Added a hosted payment page / iFrame integration using NMI's Collect Checkout to support the sunset of an outdated BAC Credomatic PSP that no longer met PCI DSS Type A compliance requirements. Card data is now collected entirely through NMI-hosted fields embedded via an iframe, so no cardholder data passes through or is stored on GO7 systems.
Improvements to Existing Features
IBE ancillary destination names
Added destination names alongside IATA airport codes on the Ancillary screen, matching the display pattern already used elsewhere in the system (e.g. Larnaca (LCA) → Haifa (HFA)). Destination names are pulled from the existing Translator module and rendered in the passenger's selected language, while IATA codes remain unchanged and are never passed through translation. The update covers all layout variants of the screen, including connecting flights with multiple segments and the Manage My Booking screen. A new Website setting controls the feature, so it remains off by default and can be enabled per company by airline administrators via the IBE settings as shown below.
Flight screen - Added OFFLK status
Added a new OFFLK status counter to the bottom of the Flight screen summary, following the same summation logic already used for the other check-in status counters. The OFFLK status indicates that a passenger or passenger segment has been removed from the flight/load, meaning the passenger is no longer considered boarded/accepted for that flight. The count reflects the number of passengers whose check-in status is OFFLK and updates automatically whenever a passenger's status changes to or from OFFLK. The counter is displayed in the same style and placement as the existing status counters for consistency.
getItinerary - Added Passenger Type for New Fare Structure
Added a new paxtype field to the getItinerary API response for each passenger, containing the passenger's type (e.g. ADULT, CHILD, STUDENT, INFANT) when a company has the Advanced Fare Structure feature enabled. This gives API users a reliable way to determine passenger type for bookings that have already been checked in via Manage My Booking, since there was previously no source for this data outside of getDeepLinkRebook. The passenger type value now correctly reflects the airline's fare structure configuration rather than defaulting non-child passengers to Adult. Companies without Advanced Fare Structure enabled will see no change in the getItinerary response.
Open Service API validation
Improved the createOpenService API's validation so it no longer incorrectly blocks requests to add an open service to a booking that was ticketed and later canceled. Previously, the endpoint only checked whether a PNR's status was OK and rejected the request on that basis alone, without accounting for a subsequent cancellation. This did not match the more permissive behavior already available in the CRS. The check now also considers whether the ticket has since been canceled and only blocks the request when the PNR remains ticketed and active. This brings the API's behavior in line with the CRS and unblocks integrations that need to add open services after a ticket cancellation.
Invoice Items (New Fare) report improvements
Improved the Invoice Items (New Fare) report, which is used heavily by airline accounting teams with the New Fare Structure, to fix three long-standing calculation issues. Tax totals on credit invoices now display as negative values so they correctly offset the summary totals. Taxes now include VAT pulled from each service's own fare-level VAT rate rather than an incorrect company-level setting, so a flight taxed at one rate and a zero-rated ancillary on the same invoice are each calculated correctly. A new Base Fare (excl. VAT) column has also been added between the existing Fare (no VAT) + Taxes and Item Fare (inc. VAT) columns, covering every service type, including ancillaries and discounts. The underlying report query was optimized to resolve a timeout customers were experiencing on larger date ranges, with the new query verified to produce identical results to the previous version across ten parameter combinations.
Bug Fixes
Session cross in MMB leads to PNR data corruption when using multiple tabs
Fixed an issue where opening two different bookings in separate browser tabs in Manage My Booking could cause data to bleed between sessions, so a flight segment or passenger count from one PNR was incorrectly written into another. Manage My Booking sessions are now bound to a single PNR, and loading a different booking in another tab immediately invalidates the previous tab's session rather than allowing both to remain active. Users are shown an alert explaining that their previous session was disconnected and that they should continue only with the newly loaded booking. Existing single-tab amendment flows, ticketing, payments, and ancillary handling are unaffected by the change.
reCAPTCHA token not sent in submit request on dynamic form
Fixed an issue on dynamic forms where the g-recaptcha-response token was not included in the submit request even after a user successfully completed the reCAPTCHA challenge, causing the form to be rejected with a "please validate you are not a robot" error. The form submission and reCAPTCHA integration were reviewed and corrected so the token is now properly appended to the request sent to the form handler.
Incomplete check-in records created during IBE online check-in
Fixed an issue where an incomplete online check-in from Manage My Booking could leave a blank check-in record in place, and a later correction made by airline staff from PSS would create a second, duplicate record instead of updating the existing one. This resulted in two entries per passenger on the flight display passenger list: one blank record and one properly checked-in record.
Login slowness
Fixed a login performance issue caused by concurrent login attempts from the same user, which had been blocked by a database row lock on the login counter while external calls to the 2FA service and logging remained open without a timeout. Timeouts and fail-closed handling have been added to those calls, the login query was optimized to avoid a costly cross-database subquery, and the login counter update was made atomic to remove the lock contention.
Rebooking issue with the inbound flight
Fixed an issue where rebooking only the inbound flight of a round-trip booking could be blocked if the unchanged outbound flight's booking class had since been closed for sale, because the outbound segment was being revalidated against current availability even though it was not being modified.
Unable to complete check-in
Fixed an issue where online check-in could fail for one passenger in a multi-passenger booking and leave the PNR stuck mid-process, along with a related case where an excess PNR was left showing payment in progress even after payment had completed. The check-in process now completes end-to-end without hanging across paid, free, and mixed seat allocations, and behaves correctly whether or not the "Auto assign seats on check-in" setting is enabled.
ReserveSeats - Excess ancillary (zero price) on New IBE
Fixed an issue where reserving a zero-priced seat on an already-ticketed booking through the new IBE's reserveSeats API incorrectly created a new Excess Seat PNR, even though no payment or invoice was required. The unnecessary Excess PNR was left unticketed, which could in turn block Online Check-In for the booking. Zero-priced seats are now added directly to the original ticketed PNR instead of generating a separate Excess PNR, while paid seats continue to follow the existing Excess PNR and payment flow unchanged.
IBE customer address validation
Fixed an issue where customer addresses containing certain punctuation, such as periods or semicolons, silently blocked bookings on the IBE. Because the offending address field was located in the non-mandatory "Add more details" section, the resulting validation error was hidden and gave customers no indication of what was wrong. Dots and semicolons are now permitted in address validation. When a validation error does occur, the "Add more details" section is now clearly marked so customers can find and correct the problem instead of getting stuck mid-booking.
Unable to update the flight number for an existing charter flight
Fixed an issue where the flight number on an existing charter flight could not be updated after the charter flight was first created without one. Because the Flight Number field is optional, a charter flight could be saved with it left blank, but reopening the flight afterward and entering a number silently failed to save, leaving the field empty no matter how many times it was re-entered. The save logic has been corrected so a flight number entered on an existing charter flight is now persisted correctly. This has been verified in DEV against the reported reproduction case.
getItinerary API returned an inconsistent source value for PNRs paid via the website after CRS creation
Fixed an issue where getItinerary returned Source: API instead of Source: PSS for a PNR originally created in CRS (pnrSource=0) that later received payment through the website (pnrSource=3), because its CASE statement was missing a condition already present in getBooking's equivalent logic. getItinerary now includes the missing pnrAGTid = 0 AND pnrCreatedbyUSR > 3 condition, so it correctly resolves to PSS, which is getItinerary's own term for what getBooking reports as CRS, for this scenario. getBooking's separate CRS reporting for the same case was left unchanged, since getBooking is being deprecated in favor of getItinerary going forward. All other existing pnrSource, UTM, and API source scenarios already covered by getItinerary are unaffected.
Comments