Exchange, Refund, and Void Guide

This guide summarizes the options and workflows in the JSON APIs for voiding, exchanging, or canceling and refunding itineraries for both NDC and GDS.

In this guide:

• Basic Concepts
• Exchange, Refund, and Void Support
• GDS Exchange Workflow
• NDC Exchange Workflow
• GDS Exchange Ticketing
  • Multi-Offer Exchanges
  • Exchange Search
  • Remarks in Exchanges
  • Form of Payment (FOP) (multiple FOP, forfeit residual amounts, waive change fee)
  • Payment
  • Commit Workbench (ticket now or hold booking)
• Supported NDC Exchange Options
• Supported GDS Exchange Options
  • Supported Changes
  • Supported Ticketing Options
  • Exchange and Refund Handling
  • Currently Unsupported

Basic Concepts

This section discusses the terms for the actions that are available once a held booking (reservation created but not yet paid for or ticketed) has been ticketed (payment has been made and ticket/s issued).

In general, after a ticket is issued, it can be voided, canceled, or exchanged, which may result in a refund, as follows:

• Void: Cancel the ticket for a full refund within an allowed void period, based on the airline's rules for the market in which the ticket was issued. Generally a ticket can be voided within the same day it was issued, usually up to midnight local agency time. In some instances it may be voided up to midnight of the day after ticketing, or special holiday policies may apply.

• Cancel: Cancel the ticket after the void period without rebooking another itinerary. Depending on the fare rules, canceling a ticket may result in a full, partial, or no refund.

• Exchange: Modify the air itinerary on a ticket and issue a new ticket for the modified itinerary.

These terms apply to how a ticket can be refunded or exchanged:

• Automated refund: A refund processed entirely within the JSON APIs, from requesting a quote for the refund and any penalties through processing the cancellation.

• Manual refund: Information about the refund amount and any penalties are obtained from a source other than the JSON APIs, and the JSON APIs process the cancellation. Not supported in the JSON APIs.

• Voluntary refund or exchange: The passenger or travel agency initiates the refund or exchange.

• Involuntary refund: The airline cancels the ticket, such as if a flight is canceled and the passenger cannot be rebooked. Not supported in the JSON APIs.

Exchange, Refund, and Void Support

The table below lists the actions available for held bookings and ticketed itineraries for both GDS and NDC content.

As discussed in the NDC Guide, NDC carriers directly handle ticketing and servicing for NDC content. Because of this, the JSON APIs use different processes to carry out post-ticketing actions for GDS and NDC content.

In addition, NDC support for the processes below vary by carrier. For example, some NDC carriers allow you to hold an exchange as a held booking and ticket it later, while others require the exchanged itinerary to be ticketed upon Resell. When working with NDC carriers, see NDC capabilities by airline through JSON API in the Travelport Knowledge Base. If you need login assistance, see Knowledge Base NDC Resources.

Action	Workflow for GDS	Workflow for NDC
Cancel a held booking	GDS Reservation Cancel	Post-commit workbench Order Cancel
Modify air itinerary on a held booking	Not supported. Cancel reservation per above and rebook.	Post-commit workbench Reshop Reprice To issue tickets at resell, send Form of Payment and Payment (NDC carrier requirements vary; some carriers require a modified booking to be ticketed on commit) Resell
Void a ticket within void period for full refund	GDS Ticket Void	Post-commit workbench Refund Quote Order Cancel
Cancel a ticket after the void period and issue refund (automated refund)	Not supported (under development)	Post-commit workbench Refund Quote Order Cancel This workflow cancels the ticket and issues a refund to the original form of payment, if the ticket is eligible for a refund. Refund Quote is mandatory when canceling a ticket outside the void period and there is any difference between a refund due and the purchase price. If Refund Quote is not sent, and a refund is not available for the exact amount of the purchase price, Order Cancel returns the error message OFFER CANNOT BE CANCELED WHEN REFUND AMOUNT DOES NOT EQUAL OFFER PRICE. PERFORM A REFUND QUOTE AND TRY AGAIN. This workflow offers the following options for supporting carriers: Retain segments: Cancel only specified segments on the ticket by sending a product identifier along with the offer identifier in the Refund Quote request. Retain tickets: Either within or after the void period, cancel the ticket but retain the ticket value by setting the RetainFlag header parameter in Order Cancel to true. You may be able to apply the value of the ticket to another booking using the Ticket as FOP API. For carrier support, see Retain Segments and Retain Tickets in NDC capabilities by airline through JSON API in the Travelport Knowledge Base.
Exchange ticket for new itinerary	Exchange Eligibility (optional) Post-commit workbench Exchange Search Add/Modify Offer In case of an even exchange or add collect ((price of new itinerary is greater than existing itinerary), Form of Payment and Payment Commit workbench, setting PayLaterInd indicating whether to issue ticket/s at commit	Post-commit workbench Reshop Reprice In case of an even exchange or add collect (price of new itinerary is greater than existing itinerary), Form of Payment and Payment may be required Resell; if a partial refund is due, new tickets are issued at Resell and the refund is credited to the original form of payment. If a payment is due or the amount is an even exchange: To issue the new tickets at commit, send the Add Form of Payment and Add Payment requests before Resell. For an even exchange, send Add Payment with a zero amount. To hold the booking, do not add any payment information in this workbench. NDC support for exchanges varies by carrier. Some carriers support exchanges only for fully unflown itineraries while others exchange partially flown itineraries. Some carriers do not support held bookings at exchange and require that payment is sent and tickets issued at Resell. See NDC capabilities by airline through JSON API in the Travelport Knowledge Base.
Manual refund	Not supported	Not supported
Involuntary refund	Not supported	Not supported

GDS Exchange Workflow

The GDS exchange workflow shops for a new itinerary to update the currently ticketed itinerary. Exchange ticketing supports automated exchanges, in which the JSON APIs are used for all steps of the exchange.

Step #	Booking Workflow Step	Description and Notes	API Reference
optional	Exchange Eligibility	Optional but recommended. Exchange Eligibility determines whether a ticket has value in an exchange or refund scenario, and the range of any associated exchange fees.	Exchange Eligibility API Reference
1	Post-Commit Workbench	Initiate a workbench for the existing booking.	Post-Commit Workbench API Reference
optional	Add seats	The exchange ticketing workflow supports seat maps and booking per the Seats Guide.	Seats Guide
optional	Add ancillaries	The exchange ticketing workflow supports certain paid ancillaries per the Ancillaries Guide.	Ancillaries Guide
optional	Add comments and service requests	The ticketing workflow supports remarks and service requests.	Remarks & Service Requests Guide
2	Exchange Search	Search for a new or modified itinerary. Supports optional journey and pricing search modifiers. Both types of modifiers are applied at the journey level, not to individual legs of the itinerary.	Exchange Search API Reference
3	Add/Modify Offer	Add an offer from the Exchange Search response to replace or update the current itinerary. The API 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.	Add/Modify Offer API Reference
4 may be optional or required	Add Form of Payment	Add Form of Payment is mandatory when there is an add collect (additional payment is due for the new itinerary). Optionally, you can use the Add Form Of Payment request to forfeit residual value, waive a change fee, or add an additional or alternate FOP.	Add Form of Payment API Reference
optional	Send remarks or comments.	Optional. Exchange ticketing supports document overrides, reservation comments, and accounting remarks. See Remarks in Exchanges below.	Remarks & Service Requests Guide
5	Add payment	Required even if you will not ticket the reservation at commit. Send Add Payment request to link the FOP to one or more offer/s to pay for. Returns a confirmation identifier.	Add Payment API Reference
6	Commit the workbench	Required. Send Commit Workbench with the payLaterInd parameter indicating whether to issue ticket/s now or later.	Commit Workbench API Reference

The following exchange ticketing workflow diagram does not include optional actions listed above such as adding seats and ancillaries.

The form of payment (FOP) step is required only in the case of an even exchange or 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.

NDC Exchange Workflow

In the following diagrams, each box represents one API call in the workflow. Itinerary changes on a held booking or a ticket exchange are shown first, then the ticket cancel and refund workflow.

GDS Exchange Ticketing

The following sections provide usage details for the APIs in the GDS exchange ticketing process.

Multi-offer Exchanges

Exchanges are supported in all the Exchange APIs for multiple tickets (multi-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 Search

Use Exchange Search to search for new options for the exchange. For each offer returned, the response details the differences in base fare, taxes, fees, and total price between that offer and the current itinerary.

The Search request must include criteria for the new search, and the identifier for the current, ticketed offer.

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. To search for changes to a specific leg, send only the product identifier/s for the leg/s 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. For any leg not sent in the request, Exchange Search returns the existing itinerary on that leg, and the exchange process retains any unmodified leg or legs.

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.

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.

Remarks in Exchanges

The following optional remarks are supported in a ticket exchange workbench after adding the offer and before adding FOP or payment. You can add remarks whether you are ticketing at commit or create a held booking for the exchange.

Document overrides: See Document Overrides in the Remarks & Service Requests Guide for these:

• Commission
• Tour code
• EMD endorsements
• Adding or modifying a ticket designator
• Overriding a change fee collection method

Reservation remarks: Sent in the Reservation Comments payload and include vendor, OSI, itinerary, and notepad remarks. Add or delete supported. See Reservation Comments in the Remarks & Service Requests Guide.

Accounting remarks: These are sent in the Accounting payload and include historical, accounting, and DOCI remarks. Add or delete supported. See Accounting Remarks in the Remarks & Service Requests Guide.

Form of Payment (multiple FOP, forfeit residual amounts, waive change fee)

Add Form Of Payment is required for an exchange only if there is an add collect (additional payment is due for the new itinerary). In this case you cannot use the FOP on the existing reservation. FOP is not required if the modified itinerary costs the same as or less than the original itinerary.

Optionally, you can send Add FOP to forfeit residual amounts, waive a change fee, or add multiple FOPs for an add collect.

Forfeit residual amounts

When exchanging a ticket, you can choose to forfeit the total residual amount, the base amount, the total taxes, or individual taxes with a tax code.

To do so, send Add FOP with the FormOfPaymentForfeit payload. In the subsequent Add Payment request, send either Amount, BaseAmount, or Taxes to specify whether to forfeit the total residual amount, the base amount, the total taxes, or individual taxes. See Add FOP and Add Payment for payloads and examples.

To forfeit for only specific traveler/s, include the traveler ID in the Add Payment request. If no traveler ID/s are sent, the forfeit is automatically applied to all travelers on the reservation.

Waive a change fee

You can waive a change fee with or without a waiver code. Waiver forms of payment are automatically applied to all travelers in a reservation.

To do so, send Add FOP with the FormOfPaymentWaiverCode payload and refer to that FOP in the subsequent Add Payment request. See Add FOP and Add Payment for payloads and examples.

Add multiple FOPs for add collect

When an add collect is due (which may include a change fee), you can choose to use multiple forms of payment for a single traveler (for BSP only), or use a different or multiple forms of payment for each traveler on the same itinerary.

To add multiple FOP, repeat the Add Form Of Payment request as necessary with one of the supported payloads in the Add Form Of Payment API Reference.

Note the following:

Change Fee to EMD:

• A change fee cannot be split across multiple FOPs.

• The first payment referenced will be used for the change fee and will not be used for the add collect.

• If a change fee to EMD is being collected during an exchange, then the first FOP referenced in the Payment service will be used for the change fee and any other FOPs referenced will be used for the add collect (if applicable).

Add Collect:

• A maximum of three FOPs can be used for one ticket – for BSP only.

• ARC does not allow multiple FOPs for an add collect.

When adding FOP:

• Do not add FOPs that already exist in the workbench, unless it’s a credit card for which only the expiration date has changed.

• Supported FOPs are cash, invoice, and credit card.

When adding payment:

• Always send a traveler reference in TravelerIdentifierRef.

• When splitting payments across one ticket, ensure the amounts in Add Payment request add up to the total add collect and/or change fee.

• Always send the Amount object in the Add Payment step even if the value = zero (e.g., forfeit scenario).

Payment

Sending Payment is required in the exchange workflow even if you will not ticket the reservation at commit.

In exchange ticketing, you can send Payment specifically for a change fee by including the Fees object in the payload. For example, if an exchange results in an add collect plus a change fee, and you want to use a different FOP for each, send one Payment request for the add collect and a second request for the change fee. You do not need to send multiple Payment requests when using the same FOP for all amounts to be collected; in that case, in the same Payment payload, send Amount/value for the add collect and Fees/Total Fees for the fees to pay for.

You can also use Payment to forfeit a tax amount by sending the Tax object with the amount to forfeit.

You cannot split an EMD into multiple payments.

See Payment API Reference for the payload and examples.

Commit Workbench (ticket now or hold booking)

Last, send the Workbench Commit to commit the changes. Set the payLaterInd query parameter to either issue the new ticket/s now, or create a held booking for later fulfillment. The only difference in exchange ticketing from initial ticketing is that the payLaterInd and DocumentValue parameters are supported only for exchanges.

There is no message payload.

The Commit response returns all details of the new reservation, including price modifications in the ModifyPrice object. Any refund issued is indicated in FulfillmentMethod/RefundMethod/value. The reissued ticket numbers are returned in an instance of Receipt of type ReceiptPayment as shown below. The response does not include any itinerary data from the previous booking.

The commit response returns the following Document @type values:

• The previous (exchanged) ticket details are returned with Document @type DocumentTicketExchange.

• The newly issued ticket details are returned with Document @type DocumentTicket.

• If an EMD is issued during the exchange, such as for a change fee or a residual balance, the commit response returns Document @type DocumentEMD with the EMD number and the amount.

When travel originates outside the country of ticket issuance, the commit response returns the fare and ticket in the currency where the travel originates from, followed by the currency of the ticketing country. For example, for a ticket sold in Australia for travel commencing in the US, the base fare is returned in USD and the EQ/TTL fare is in AUD.

Supported NDC Exchange Options

In general, NDC supports the following changes on either a held booking or a ticketed itinerary:

• Modify the date, time, flight, cabin, or origin and/or destinations

Ticket exchanges are supported for the following:

• Automated exchanges
• One-way, round-trip, interline, and open-jaw itineraries
• Bookings with up to 9 passengers
• All PTC codes

Carrier support varies for the following:

• Adding new air segments

• Modifying seats or ancillaries

• Modifying or adding flights after travel comments

• Canceling a booking with ancillaries or seats

• Canceling a divided booking.

See the Cancel section in NDC capabilities by airline through JSON API in the Travelport Knowledge Base. If you need login assistance, see Knowledge Base NDC Resources.

Supported GDS Exchange Options

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

Supported Changes

Supported itinerary changes are as follows:

• Changes to outbound and inbound dates and times, origins, destinations, independently or together for outbound and inbound
• 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
• Bookings 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 GDS Exchange APIs do not currently support:

• Manual exchanges
• NDC content (handled with the Reshop, Reprice, and Resell APIs)
• 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/divided tickets
• 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.