GDS Exchanges Guide

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

  • Eligibility determines 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 to exchange for a currently ticketed itinerary.
  • Add/Modify Offer selects an offer from the Exchange Search results to use to modify the existing itinerary.
  • Exchange Ticketing adds payment and either issues the ticket or holds for later. It also supports change fees or waivers when applicable.
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 under development.

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

In this guide:

Basic Concepts

After the void period, in which a ticket can be canceled for a full refund, a ticket can usually still exchanged if changes to the itinerary are needed. An exchange cancels all or part of the original air itinerary on a ticket and issues a new ticket. The fare rules for the ticketed fare determine the cost, if any, of an exchange and whether the value of the previous ticket can be applied to the new ticket.

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, is not supported.

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

Exchange Workflow

Exchange Ticketing supports automated exchanges, in which updates are made and new ticket/s issued using the JSON APIs.

Automated Exchanges

The automated 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. Send an Add/Modify Offer reference payload request to send identifiers from the Exchange Search response for the offer to use to update the itinerary.
  5. In Exchange Ticketing, take the following actions as applicable:
    1. If there is an add collect (additional payment is due for the new itinerary), you must send the Form Of Payment request with the payment method to use for the additional amount.
    2. As needed, use the Add Form Of Payment request to forfeit residual value, waive a change fee, or add an additional or alternate FOP.
    3. Add document override remarks using the Document Overrides payload. Optional.
    4. Add or delete reservation comments using the Reservation Comments endpoints. Optional. Exchange Ticketing 24.11.26 and later.
    5. Send Add Payment request. Required.
    6. Send the Commit Workbench request with the payLaterInd parameter indicating whether to issue ticket/s now or later. Required.

Exchange Workflow Diagrams

The form of payment (FOP) step is required only if an additional amount is due. Otherwise, FOP is optional and can be used to send a waiver code, forfeit residual amounts, or add an additional FOP.

Multi-offer Exchanges

Exchanges are supported in all the Exchange APIs for multiple tickets (offers) for a single passenger, and for multiple tickets for multiple passengers, subject to the following:

  • Multi-offer exchanges are supported only for segments with fares quoted separately.

  • A single workbench session supports exchanging only one offer, for either a single or multiple passengers. To exchange additional offers, use another workbench session for each offer. For example, if you want to modify both legs of a round-trip ticket for three passengers, and each leg of the round-trip is a separate offer, first complete the exchange workflow for the outbound/departure leg for all three passengers, and then in another session complete the workflow for the inbound/return leg for all three passengers.

  • Your PCC must be provisioned for exchanging multi-offers or an error message is returned. Contact your Travelport representative if necessary.

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.
Travelport+ (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 o, e.g., 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.

Add/Modify Offer

The Add/Modify Offer API sends identifiers from a preceding Exchange Search response to select an offer from those search results to modify the offer on the current itinerary. The system compares the existing itinerary with the new itinerary, deletes any flight segments no longer needed, and adds the new flight segments. Any unmodified segments remain as they are.

The Add/Modify Offer reference payload request supports the automated exchange workflow, in which updates are made and new ticket/s issued using the JSON APIs, Manual exchanges, which ticket a modified itinerary after making updates outside the JSON APIs, are not supported.

Exchange Ticketing

Exchange Ticketing uses the standard JSON AirTicketing APIs - Add Form of Payment, Add Payment, and Commit Workbench - and uses additional objects or parameters that are specific to exchanges. At workbench commit, you can choose whether to hold or ticket the modified itinerary.

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
  • Tax is supported in BSP markets
  • Overriding the change fee collection method is supported with document override remarks

Currently Unsupported

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)
  • Unworked schedule changes (i.e., tickets with unaccepted flight changes)
  • Tickets with the same PTC types priced separately.
  • Tickets that have been previously exchanged outside the JSON APIs.
  • Split/divide ticketing
  • Unaccompanied minors
  • No-show scenarios
  • Category 16 data
  • Carriers that don’t file Category 31 (voluntary changes) and Category 33 (voluntary refunds) rules data. 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.