Exchange Ticketing Guide / API Reference

Exchange Ticketing is the last step in the GDS exchange workflow. Per below, Exchange Ticketing uses the standard JSON AirTicketing APIs - Add Form of Payment, Add Payment, and Commit Workbench - with additional objects or parameters that are specific to exchanges. At workbench commit, you can choose whether to hold or ticket the modified itinerary.

It follows the Exchange Eligibility, Exchange Search , and AddModify Offer APIs, which confirm eligibility, search for a new itinerary, and choose a modified itinerary from the search results.

This combined guide and API reference provides the POST requests and examples for all requests in the workflow.

Related Content: GDS Exchanges Guide, Cancel, Exchange, and Refund Options

In this guide:

Remarks in Exchanges

The following specific remarks are supported in an exchange workbench.

Document Overrides (optional)

As an optional step, you can send a document override request. You must send the request after adding the offer and before adding FOP or payment.

Exchange Ticketing supports the following document overrides to the exchange process; for payloads and usage details see Document Override Remarks for GDS Exchanges in the Remarks & Service Requests Guide:

  • Commission
  • Tour Code
  • EMD Endorsements
  • Adding or modifying a ticket designator
  • Overriding a change fee collection method

Reservation Comments (optional)

Exchange Ticketing 24.11.26 and later.

You can add or delete reservation remarks during the exchange process. These remarks are sent in the Reservation Comments payload and include vendor, OSI, itinerary, and notepad remarks. Remarks can be added or delete for both issuing tickets or holding the booking at workbench commit.

See Reservation Comments in the Remarks & Service Requests Guide for endpoints and payload details.

Accounting Remarks (optional)

Exchange Ticketing 24.11.26 and later.

You can add or delete accounting remarks during the exchange process. These remarks are sent in the Accounting payload and include historical, accounting, and DOCI remarks. Remarks can be added or delete for both issuing tickets or holding the booking at workbench commit.

See Accounting Remarks in the Remarks & Service Requests Guide for endpoints and payload details.

Add Form of Payment

A Form of Payment (FOP) request is required 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 less than the original itinerary, or in the case of an even exchange.

To add a form of payment when necessary, send a request to the endpoint below with one of the payloads (cash, credit, agent invoice) detailed in the Add Form Of Payment API Reference.

Optionally, you can send an FOP request per the following sections to use multiple forms of payment, forfeit residual amounts, or waive a change fee.

All steps in this section use the following endpoint with the payload detailed below for each. This is the same endpoint used to add FOP in initial ticketing. The response returns a confirmation identifier.

POST

payment/reservationworkbench/{workbenchID}/formofpayment

For {workbenchID} send the workbench identifier returned in ReservationResponse/Identifer/value in the workbench create response.

Base path:

Pre-production https://api.pp.travelport.com/11/air/

Production https://api.travelport.com/11/air/

Add Multiple Forms of Payment (optional)

Adding multiple FOP is supported only when issuing tickets at workbench commit, as this information is not cached for later ticketing.

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 payloads (cash, credit, agent invoice) detailed 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 3 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 below:

  • Always include a traveler reference.

  • 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).

Forfeit Residual Amounts (optional)

Forfeiting residual amounts is supported only when issuing tickets at workbench commit, as this information is not cached for later ticketing.

Optionally, agencies can forfeit residual amounts during the exchange/reissue of a ticket. An agency can forfeit the total residual amount, the base amount, the total taxes, or individual taxes with a tax code.

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

To send FOP to forfeit residual amount:

  1. Send an FOP request to the FOP endpoint above with the Add FOP Forfeit Request payload below. Include the FormOfPaymentForfeit object.

  2. When you send the add payment request in the next step below, reference the FOP identifier for the Forfeit and send one of the following objects as appropriate to identify the amount to forfeit:

    1. Total residual amount: Amount object, example: "Amount": { "code": "USD", "value": 863.40 }

    2. Base amount: BaseAmount object, example: "BaseAmount": { "code": "USD", "value": 123.45 } }

    3. Total taxes: Taxes object with TotalTaxes, example: "Taxes": { "@type": "TaxesDetail", "TotalTaxes": 23.0 }

    4. Individual tax: Taxes object with individual Tax object, example: "Taxes": { "@type": "TaxesDetail", "Tax": [ { "currencyCode": "USD", "taxCode": "YQ", "value": 34 } ] }

Waive a Change Fee (optional)

Waiving a change fee is supported both for ticketing at workbench commit and ticketing later.

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.

WaiverCode/value is optional and if sent is added to the Endorsement Box in the reservation.

To send FOP to waive a change fee:

  1. Send a request to the FOP endpoint above with the Add FOP Waiver request payload below.

  2. When you send the add payment request in the next step, reference the FOP identifier for the waiver code.

Add Payment

Add Payment is a mandatory step in the GDS exchange workflow. In the case of even exchange or a refund, send Add Payment with Amount/value with 0 (zero).

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

Send the Add Payment request to the endpoint below, which is the same endpoint used to add payment in initial ticketing.

If necessary, you can send a separate Add Payment request specifically for the change fee, per the second example below. For example, if an exchange results in an add collect plus a change fee, and you want to use a different FOP for each fee, send one Add Payment request for the add collect and a second request for the change fee. You do not need to send multiple Add Payment requests when using the same FOP for all amounts to be collected; in that case, send Amount/value separately from Fees/Total Fees.
You cannot split an EMD into multiple payments.

POST

paymentoffer/reservationworkbench/{workbenchID}/payments

For {workbenchID} send the workbench identifier returned in ReservationResponse/Identifer/value in the workbench create response.

Base path:

Pre-production https://api.pp.travelport.com/11/air/

Production https://api.travelport.com/11/air/

The response returns a confirmation identifier.

Commit Workbench (Ticket Now or Hold Booking)

Last, commit the workbench to commit the changes, setting the payLaterInd query parameter to either issue the new ticket/s now, or create a held booking for later fulfillment.

Send the request to the following endpoint. This is the same endpoint used to commit any workbench. The only difference is that the payLaterInd and DocumentValue parameters below are supported only for exchanges.

There is no message payload.

POST

book/reservation/reservations/{workbenchID}

For {workbenchID} send the workbench identifier returned in ReservationResponse/Identifer/value in the workbench create response.

Base path:

Pre-production https://api.pp.travelport.com/11/air/

Production https://api.travelport.com/11/air/

Query parameter Description Require

payLaterInd

Required in Exchange Ticketing 23.11.13 and later.

Sets whether to issue the new ticket/s now, or create a held booking for later fulfillment. Supported values:

true: Holds changes for later fulfillment and ticketing.

false: Issues ticket and any other documents such as EMDs on commit.

Required

DocumentValue

If sent, send with a value of REFUND, which refunds an EMD that has a refundable balance to the original FOP and is the only supported value.

Refunds are indicated in the Exchange Search response by a negative amount in ModifyPrice/TotalPrice, and a value of either EMD or MCO in TermsAndConditions/FulfillmentMethod/RefundMethod.

Alternately, you can refund or forfeit any EMD value using the EMD Void request.
If the new itinerary is ticketed at the time of reservation (pay now flow), and there is a residual balance to an MCO (miscellaneous change order), the MCO is issued along with the ticket at workbench commit. If the new itinerary is booked but not ticketed (pay later flow), any MCO is created but not issued yet. This allows customers to display, modify, and issue their own MCO outside of the JSON APIs if desired. If the reservation is subsequently ticketed using Exchange Ticketing, the MCO is issued as usual at commit.

Optional

If not sent any value remains on the EMD.

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.