Ticketing Guide

AirTicketing uses a workflow of multiple calls to ticket an existing reservation: create a workbench, issue payment, and commit the workbench. The difference between ticketing and booking is that payment is sent in the ticketing workbench. At workbench commit, that payment is applied and ticket/s issued.

This guide summarizes the required and optional steps in the ticketing workflow. Endpoints, requests, responses, and examples are provided in the API Reference for each step, linked below.

Additional options:

• You can verify booking details prior to ticketing with a Reservation Retrieve.
• You can add certain remarks and service requests to the reservation before ticketing.

Related Content: JSON APIs Guide, Booking Guide, Ancillary and EMD Guide, Cancel, Exchange & Refund Options

In this guide:

• Basic Concepts
• AirTicketing Workflow Summary
• AirTicketing Workflow Diagram
• Ticketing Commit Response Layout Diagram
• Optional Actions at Commit
  • Accept Involuntary Schedule Change
  • Specify a Queue
  • Add Ticket to Back Office Systems

Basic Concepts

AirTicketing uses a workflow of multiple calls to create a workbench, issue payment, and commit the workbench to ticket an existing reservation. Generally, a ticket is issued for a held booking, which is a reservation that has already been created with the booking workflow. In the Instant Pay workflow only, supported only for NDC, booking and ticketing take place in the same workbench session.

The step that sets ticketing apart from booking is that a paymentis added to the workbench with the Add Payment request, and on commit that payment is applied and ticket/s issued. Add Payment can be used to pay for the offer/flight, paid seats, or other paid ancillaries. Add Payment must reference both the offer being paid for and the form of payment (FOP)to be used to pay for that offer. FOP can be added during booking for GDS or at ticketing for both GDS and NDC.

Tickets are itinerary receipts issued for each passenger in the itinerary, including infants, when payment is sent as part of the workflow. Document tickets are issued for air offers (the flight itself) while document EMDs are issued for paid ancillary and seat offers, which are identified the ticket type code J or Y. No tickets are issued for free seats. Every ticket has a 13-digit code that includes the airline's 3-digit ticketing code, 4-digit form number, and 6-digit serial number.

For GDS content, tickets are issued by the Travelport host system, while tickets for NDC content are issued directly from the airline. Because of this, you'll notice some differences in how ticketing and related functions are handled by the JSON APIs. These differences are noted here in the help as applicable.

After ticketing, you can retrieve ticket details with any of the following:

• Reservation Retrieve: Lists itinerary, offer, and price details for all travelers on a reservation. If the reservation has been ticketed, returns ticket number/s in the Document/Number object.

• Ticket Retrieve: For the single ticket number sent in the request, returns basic itinerary, price, and ticketing details such as fare, passenger name, flight origin and destination, and ticketed date.

• Ticket List: Returns a list of all ticket numbers on a reservation. Does not return ticket details.

AirTicketing Workflow Summary

The AirTicketing workflow uses the following HTTP requests summarized in the following table and detailed below.

Step #	Booking Workflow Step	Description and Notes	API Reference
1	Create post-commit workbench	Initiate a workbench for an existing booking by sending the reservation locator code in the POST request. This is a prerequisite step for any transaction that modifies, updates, or tickets an existing reservation.	Create Post-Commit Workbench API Reference
optional	Add seats	Seat availability and selection may be supported in the ticketing workflow as per the Seats Guide.	Seats Guide
optional	Add ancillaries	Certain paid ancillaries are supported in the ticketing workflow as per the Ancillaries Guide.	Ancillaries Guide
optional	Add comments and service requests	Certain remarks and service requests can be added in the ticketing workflow.	Remarks & Service Requests Guide
2	Add form of payment if not already present	Add the form of payment (FOP) to be used for the payment. Cash, credit card, non-standard credit card, and agent invoice FOPs are supported. The response returns a system-generated identifier for the FOP that is part of the reservation record and sent in the subsequent Add Payment request. For GDS, sending FOP in booking is optional and, if sent, is stored and retrieved during ticketing. If not sent in booking, FOP is required at ticketing. For NDC, adding FOP during a held booking is not supported and must be added at ticketing. Add Multiple Forms of Payment (GDS only) For GDS only, you can send up to two FOP in either the booking or ticketing workflow by repeating the Add Form of Payment step for each FOP. Note that at ticketing you must send a separate Add Payment request for each FOP. Multiple FOP are currently supported only for bookings with a single passenger. The additional FOP can be credit card, non-standard credit card, or cash. Non-Standard Credit Cards When sending payment with a non-standard credit card, send inhibitPaymentCardAuthorizationInd with a value of true. Unused Ticket as Form of Payment (NDC only) For NDC only, on carrier American Airlines (AA) only, the JSON APIs support using an unused ticket as form of payment (FOP) to pay for ticketing a separate, held booking. To do so, send the OfferQueryBuildFromOffer request detailed in the Ticket as FOP API Reference. before the Add FOP request. You need to send FOP and payment only if the cost of the new booking exceeds the available value on the unused ticket.	Add Form of Payment API Reference
3	Add payment	The Add Payment step sends the payment. It must reference both the FOP to be used for the payment and the offer to pay for. This offer could be for an itinerary, paid seats, and/or paid ancillaries. If using the same FOP, you can send multiple offer IDs, such as one offer ID for the itinerary and multiple offer IDs for the paid seats to purchase on that itinerary. If multiple forms of payment have been added, repeat the Add Payment step for each FOP. While an Add Payment request can include multiple offer IDs, such as for the itinerary and for paid seats, it supports only one FOP. In subsequent releases, AirTicketing will support linking a form of payment to a specific offer, and using a different FOP for individual offers. Returns a confirmation identifier.	Add Payment API Reference
4	Commit the workbench and issue ticket	Final step in the ticketing workflow. Issues the ticket (and EMD if applicable), discards the workbench, and returns a ticket number. Back office accounting Optionally, at commit you can send a message to update any back office accounting systems with ticket information: In the workbench commit, include the Issuance query parameter with the value BACKOFFICE. You can either: Send the accounting message before the ticket is issued: Do not include payment in the workbench, send the commit with Issuance=BACKOFFICE issue the ticket and send the message at the same time: Include payment in the workbench, send the commit with Issuance=BACKOFFICE The response includes an interface control number.	Commit Workbench API Reference

Ticketing Workflow Diagram

*Optional seats and ancillaries can be added during either booking or ticketing, or in a separate workbench session, per the support noted in the Seats and Ancillaries guides.

Workbench Commit Response Layout Diagram

The following diagram illustrates the general structure of workbench commit response for ticketing - this is the same as the Reservation Retrieve request and response. Note this diagram includes the Payment object, which is returned only after ticketing.

Optional Actions at Ticketing Workbench Commit

Although the workbench commit step at the end of the ticketing process does not require a message payload, AirReservation supports the following optional actions at commit. These optional payloads are detailed in the Workbench Commit API Reference.

Accept Involuntary Schedule Change

The indicator scheduleChangeAcceptedInd allows you to update the reservation with schedule changes when an airline has modified a flight schedule (called an involuntary schedule change). To check whether a flight schedule has been modified, send a standard Reservation Retrieve request:

• For GDS, a value in OfferStatus/StatusAir/code of either TK or UN indicates the flight has schedule change information.

• For NDC, the response returns NDC CONTENT HAS CHANGED in ReservationComment when a schedule change has occurred.

To accept the schedule change, send the workbench commit request with scheduleChangeAcceptedInd set to true. You do not need to create a workbench session first.

Specify a Queue

Each Travelport PCC has a set of numbered queues. Some of these queues have predetermined functions and others can be customized for internal use. The queue system allows you to sign into and out of queues, place booking files on a queue, and perform various maintenance functions on the booking files currently on queue.

To specify a queue for a booking, send a message payload with the QueueNumber object in the workbench commit request.

Add Ticket to Back Office Systems

Sending the optional Issuance query parameter with a value of BACKOFFICE in the workbench commit request sends a message to update any back office accounting systems with ticket information.

You can send the message before the ticket is issued by sending a commit without payment, or commit with payment and the Issuance parameter to issue the ticket and send the message. The response includes an interface control number.