GDS Exchanges Guide

Exchange functionality for GDS itineraries is handled by the Exchange APIs:

  • Eligibility allows you to determine whether a ticket has value in an exchange or refund scenario, and the range of any associated exchange fees.
  • Exchange Search supports searching for an alternate itinerary for a possible exchange on a currently ticketed itinerary.
  • Exchange Ticketing supports making changes to an existing itinerary and collecting change fees or providing refunds when applicable.

The Exchange APIs answer these questions and then allow you to exchange the ticket:

  • Can I change my booking and if so how much will it cost?
  • How much is the fare I want to change to?
You must use the Travelport JSON Exchange APIs for the full end-to-end exchange flow, starting with Exchange Eligibility and Search through the Ticketing APIs. Using an Exchange API with a non-Travelport API is not supported.
For NDC exchange functionality, see NDC Modify, Cancel, and Exchange Guide.
Refund functionality in the JSON APIs is currently under development.

Related Content: GDS Cancel, Exchange, and Refund Summary, Exchange Ticketing Guide & API Reference

In this guide:

Basic Concepts

A ticket can be exchanged when changes to an itinerary are desired, but the ticket is outside the void period in which the ticket can be canceled for a full refund. An exchange cancels the original air itinerary on a ticket and issues a new ticket. The fare rules for the ticketed fare determine what an exchange costs, if anything, and whether the value of the previous ticket can be applied to the new ticket.

At this time all ticket exchanges must take place fully within the JSON Exchange APIs, called an automated exchange. A manual exchange, in which the JSON APIs are used to ticket an itinerary modified outside the JSON APIs, are not currently supported.

See GDS Cancel, Exchange, and Refund Summary for more about void, cancel, and exchange options.

Exchange Workflow and Diagrams

The exchange workflow consists of the following steps:

  1. Send an Exchange Eligibility request to determine eligibility for exchange. Optional.
  2. Create a post-commit workbench.
  3. Send an Exchange Search request to search for a new or modified itinerary.
  4. In Exchange Ticketing, send a reference payload Add/Modify Offer request to send identifiers from the Exchange Search response for the new itinerary.
  5. Take any of the following optional actions as desired or applicable:
    1. Send a document override remark request.
    2. Send an Add FOP request, depending if you want to forfeit residual value, waive a change fee, or add an additional or alternate FOP.
    3. Send Add Payment request (only in the case of an add collect that you want to charge to a different FOP than was used for payment).
  6. Send the Commit request with the payLaterInd parameter indicating whether to issue ticket/s now or later.
The form of payment (FOP) step is required only if there is an additional amount due. Otherwise, FOP is optional and can be used to send a waiver code, forfeit residual amounts, or add an additional FOP.

Exchange Eligibility

The Eligibility API is the first step in the GDS exchange workflow. Although an optional step, it's recommended to check a ticket's eligibility for exchange before carrying out any other steps. Eligibility returns information about whether a ticket may have value in an exchange or refund scenario, and the range of potential exchange and refund fees. This information relates only to fees and not any fare or tax difference for the itinerary.

Exchange Search

After running an Eligibility request to determine if the ticket has any value in an exchange (optional), create a post-commit workbench and run Exchange Search to return options for the exchange. The response details any differences in base fare, taxes, fees, and total price between the current itinerary and the possible new itinerary.

The ticket and reservation must still be active to use Exchange Search. The length of time a ticket remains active on a carrier varies. To verify whether a reservation is still active, retrieve the reservation. To verify whether a ticket is still active, retrieve the ticket. Valid responses indicate they are active.
Galileo (1G) currently has available functionality for automatic segment placement logic. This is controlled by the SASP field of the AAT table and must be set to true for the exchange process to work correctly.

Exchange Search Request

The Search request must include criteria for the new search, and the identifier for the current offer from the reservation. Product identifiers are optional.

You can request either a detailed or summary view. See the Exchange Search API Reference.

You can search for new options for only one leg of an itinerary and keep the other leg/s, or you can search for new options for all legs. Send only the product identifier/s for the leg or legs you want to change. (In the JSON APIs a product is one leg of an itinerary; a leg is all flight or flights between one origin and destination pair. For example, DEN>LAX and LAX>DEN could be the two legs of a round-trip itinerary.) To keep the other leg, don't send its product identifier in your search request. The offers in the Exchange Search response include the existing itinerary on any leg not sent in the request, and the exchange process retains any unmodified leg or legs.

Exchange Search Modifiers

Exchange Search supports optional journey and pricing search modifiers that restrict the flight types returned in the response. Journey modifiers allow you to set the number of connections or stops in the itinerary and are sent in SearchModifiersAir. Pricing modifiers support fare types and account codes and are sent in PricingModifiersAirChange. Both types of modifiers are applied at the journey level, not to individual legs of the itinerary.

See the Exchange Search API Reference for a full listing of supported modifiers.

Exchange Search Response

The Exchange Search response returns up to 100 offers. Offers are numbered sequentially starting with o0.0, o0.1, o0.2, etc. Each offer is returned in an instance of CatalogOffering with type CatalogOfferingModify, and includes all products and flights that make up the offer. For example, a round-trip offer would return two instances of ProductOptions, one for each leg of the itinerary.

In Exchange Search, all pricing information is inclusive of all travelers across all PTCs.

Each instance of CatalogOffering includes the following:

  • For each flight:
    • A reference ID for the flight matching to flight details consolidated across offers in the ReferenceList object.
    • Basic brand details (not ancillary details), including brand name, ID, tier.
    • The boundFlightsInd indicating that flights are bound and must be sold together (true) or can be sold point to point (false).
  • Price: Price of the new itinerary, including base price, taxes, and fees, including the amount or percentage of any change fee.
  • PriceDifference: Difference between original and new itinerary.
  • Terms and conditions of the new fare, including baggage - checked & carry on fees, price, pieces, size.
  • Any endorsements or restrictions, plus the vendor-filed base currency (currency of origin country).

Refunds and Change Fee Collection Methods

In the ModifyPrice/TotalPrice object, a negative number indicates a refund, while a positive number indicates a change fee and/or an add collect (additional amount due). The following are returned in the refund and change fee scenarios:

If the new itinerary results in a refund:

  • ModifyPrice/TotalPrice is negative
  • TermsAndConditions/FulfillmentMethod/RefundMethod is returned with one of the following values:
    • RefundToOriginalFOP: Refund automatically applied to the original FOP.
    • MCO: MCO is automatically created and issued, residual value is applied to the MCO.
    • EMD: SVC segment is created and EMD is issued for refundable amount.
    • Unknown: If Unknown and a refund amount are returned, and an exchange is carried out and committed, any residual balance will be forfeited.

If the new itinerary incurs a change fee and/or an add collect:

  • ModifyPrice/TotalPrice is positive
  • TermsAndConditions/FulfillmentMethod/ChangeFeeCollectionMethod is returned with one of the following values:
    • EMD: SVC segment is created and EMD is issued for change fee amount
    • TAX: Response will also include ChangeFeeCollectionMethodCode (with the applicable tax code). Change fee will be automatically collected as a tax at the time of ticketing.

Net Ticket Data

For any fare that has a private fare component, the response returns the following net ticket data (NTD). Note you must request net fares to return net fare ticket data.

  • Net ticket data in Product/PassengerFlight/FlightProduct in the attributes carCode (Commercial Airline Agreement number) and valueCode (value code for the fare).
  • Both Price and ModifyPrice include in their PriceBreakdown object the objects Commission (the amount of commission or the commission difference as either a percent or amount; not returned if no commission is filed or if the commission is a mix of amount and percent) and NetBaseAmount, which is the base fare filed by the airline.

See Reservation Retrieve for the NTD details returned in the Reservation Retrieve.

Exchange Ticketing

Exchange Ticketing issues the ticket for a modified itinerary and is the last step in the GDS exchange workflow. Exchange Ticketing updates to the existing GDS itinerary and processes add collects, change fees, or partial refunds when applicable. As with the AirTicketing workflow, Exchange Ticketing sends several requests in a workbench session to modify the ticket and send payment. At commit you can send the payLaterInd parameter to set whether to issue the new ticket/s now, or create a held booking for later fulfillment.

Exchange Ticketing supports making changes to an existing itinerary and collecting change fees or providing refunds when applicable. It can be used for either automated exchanges (after the Eligibility and Search requests ) or manual exchanges (after updates have been made outside the JSON APIs, or by sending new details without any previous update).

See the Exchange Ticketing Guide and API Reference for details of all steps.

Supported Exchange Options

The Exchange APIs support the search and exchange options detailed below.

Supported Changes

Supported itinerary changes are as follows:

  • Outbound and inbound date change at the same time
  • Outbound retained, inbound date change
  • Outbound retained, inbound origin change
  • Outbound retained, inbound destination change
  • Outbound retained, inbound origin, destination and/or date change
    • Inbound origin and date change, or,
    • Inbound destination and a date change
  • Inbound retained, outbound date change
  • Inbound retained, outbound origin change
  • Inbound retained, outbound destination change
  • Inbound retained, outbound origin, destination and/or date change
    • Outbound origin and date change, or,
    • Outbound destination and a date change
  • Outbound and inbound on one carrier or different carrier (interline)
  • Alternates (for the changed flight) include only nonstop/direct or one connection
  • Outbound and inbound routing change at the same time
  • Outbound and inbound date and routing (combo of one or the other) change at the same time

Supported Ticketing Options

Exchanges are supported for the following:

  • Automated exchanges
  • One-way, round-trip, interline, and open-jaw itineraries
  • PNRs with up to 9 passengers
  • All PTC codes.
  • Up to 16 segments for all products in the reservation/ticket
  • Up to 2 connections for the outbound leg and up to 2 connections for the inbound leg
  • Wholly unflown and partially flown tickets
  • Currencies with zero, two, and three decimals
  • Private fares
  • Net fares with mark up using an account code
  • Exchanges for an empty reservation, which can result when air segments and stored fares are canceled but the reservation is kept open to retain traveler and ticket information. Refer to the bullet below for a restriction on empty PNRs with the original ticket of IT/BT (inclusive tour code fares / bulk fares).
  • Bulk IT/BT tickets on CAT 35 fares. However, if the original ticket has an IT/BT and if those flights were canceled and no flights from the original ticket were flown, then the reservation is empty and the original tickets with private fares cannot be exchanged.
  • BSP EMD change fees and BSP change fee as tax
  • Payment as cash, credit, or invoice
  • Alternate form of payment (FOP) using a different credit card than used for the original ticket
  • Document Overrides:
    • Commission on fare
    • Endorsement
    • IT/BT
    • Tour Code
  • Override change fee collection method in Document Override

Other notes:

  • Changes to a reservation apply to all passengers on that reservation.
  • Exchange Search returns a response only for the ticketed passengers on an itinerary. For example, in the US market, a domestic INF on lap would not be shown in the exchange response; however, all changes will apply to that INF traveler.
  • If Exchange Search returns RefundMethod of Unknown and a refund amount, and an exchange is carried out and committed, any residual balance will be forfeited.
  • Travelport does not collect OB fees on reissued tickets.

Exchange and Refund Handling

The following applies to exchanges and refunds:

  • BSP Carriers must support EMD:
    • Change fees are collect via EMD
    • Refundable balances are automatically refunded via EMD
    • In both cases, a SVC segment is added and the EMD issued
  • ARC Carriers must support MCO:
    • Change fees are collected at time of ticketing
    • MCO is automatically issued for any negative balance (refund or retain)
  • Option to forfeit any residual value

Currently Unsupported

At this time the Exchange APIs time do not support:

  • Manual exchanges

  • NDC content (see NDC Modify, Cancel, and Exchange Guide instead)
  • Refunds without any itinerary exchange (separate refund functionality is under development)
  • PNRs with unworked schedule changes (i.e., tickets with unaccepted flight changes)
  • Tickets that have been previously exchanged (multiple reissues). If a ticket number for ticket that has previously been exchanged is sent in any of the Exchange APIs, the API returns the error message Tickets that have been previously exchanged are not currently supported for exchange processing.
  • Split/divide ticketing
  • Unaccompanied minors
  • No show scenarios
  • The use of Category 16 data
  • Carriers that don’t file Category 31 (voluntary changes) and Category 33 (voluntary refunds) rules data. Category 31 and 33 are fare rules to enable voluntary changes and refunds to be automatically calculated using industry standards

    • Category 16 is text-based information regarding exchanges and refunds. The Eligibility API relies on Category 31 and Category 33. Some carriers may not fully maintain the integrity and consistency of the data between Category 16 (text based) and Categories 31 and 33 (rule based). In such cases Eligibility relies on Categories 31 and 33.