Flight Booking in a Travel App: Reservation Confirmed or Ticket Issued?

A travel customer's booking reference should not automatically become a message saying their flight is ticketed. When commissioning an agency portal, define how a held reservation becomes an issued travel document and what staff do before its ticketing deadline. The practical consequence is a traveller seeing a reassuring itinerary while an essential supplier step remains unfinished.

This guide concerns software requirements, not permission to sell air travel, airline accreditation or an entitlement to board. Your travel operations team must approve supplier workflows and customer wording. Payment collection, ticket issue and later travel eligibility need their own evidence.

Decide which supplier workflow you are integrating

The official Travelport Flights Booking Guide describes a standard workflow in which committing a booking creates a held reservation: the airline has confirmed it, but it is not yet ticketed. Ticketing takes place in a subsequent session and a ticketing time limit applies.

The same guide documents exceptions. Its NDC Instant Pay workflow creates the reservation and tickets in the same session. For ticketless carriers, completion happens at booking commit without a separate ticketing step. A portal must therefore not impose “ticket number required” on every supplier or describe every booking as awaiting later issuance.

Ask your implementer to map the actual supported carrier and booking path. The correct rule comes from that path and the current supplier response, not a universal interpretation of the word “confirmed.” An internal request reference is not a substitute for a supplier reservation or issuance record.

Give held reservations a real operational owner

For a held booking, show the authoritative deadline, its time basis and the person responsible for completing the permitted next step. Do not calculate a universal deadline by adding a familiar period to the customer's request time. The Travelport guide returns expiry and payment-time-limit information in the booking response; use the applicable returned information and have operations resolve conflicting or missing values.

A deadline alert is useful only if staff can act. Specify what happens when required payment information is missing, the authorised ticketing employee is absent or the supplier no longer permits the original action. Do not silently issue at a changed price or promise that a reservation will remain available while someone investigates.

Customer status should distinguish “reservation held, ticketing outstanding” from “supplier outcome being checked.” Neither should look like an instruction to arrive at the airport with an already issued ticket. Agree when an unresolved case needs direct staff assistance.

Keep reservation and passenger document relationships clear

Travelport's Smartpoint Cloud ticketing instructions describe a ticketing confirmation displaying passenger information including airline, name and ticket number. That supports checking issuance evidence associated with the actual traveller rather than using a booking-level green badge alone.

For your portal, define how passenger and flight coverage are represented by the supplier's records. A multi-person itinerary should show what has actually been confirmed for each relevant traveller. Do not invent a universal one-booking-to-one-ticket relationship, and do not infer missing documents from a file uploaded by the customer.

Keep received supplier identifiers distinct from a locally generated itinerary PDF. Generating or emailing that PDF does not issue a ticket. Conversely, an issued document may exist even if a customer notification has not arrived. Let staff investigate communication and supplier outcomes separately.

Do not repair an uncertain issue by issuing again

If the supplier request times out after submission, record the attempted operation and reconcile its result using the provider-supported retrieval or operational procedure. Do not mark it definitely failed and offer another issue immediately. These are proposed safeguards for your integration, not a claim that the cited platform guarantees exactly-once issuance.

Later itinerary changes need a reviewed travel-operations workflow. Updating a departure field in your database must not imply that an existing ticket has been amended. This article does not define exchange, refund or fare rules; keep those outside an initial issuance feature unless separately specified and verified.

Accept the actual supported paths

Use a supplier-approved test environment and synthetic travellers in your acceptance criteria. Show a held reservation approaching its returned deadline, missing payment details, a completed issue, an uncertain response and a booking with several travellers. Include Instant Pay or ticketless completion only where your integration actually supports it.

The reviewer should identify the supplier reservation, the applicable completion evidence, the responsible person and the customer message. No real ticket purchase is needed for this demonstration. Bring those operational cases to a travel-app discussion. The deliverable is a reliable explanation of what has been reserved and what has been issued, not simply an attractive itinerary with a confirmation number.