Overview

Complete a flight reservation by confirming a prebook and processing payment. This is the final step in the booking flow.

When to Use

• Final booking confirmation - Convert a prebook into a confirmed booking
• Payment completion - Confirm with Stripe (TRANSACTION_ID), bill an enabled credit line (CREDIT), pay with a credit card (CREDIT_CARD via the secure endpoint), or charge the card stored on your account (ACC_CREDIT_CARD)
• After service selection - Book after optionally attaching seats or baggage via the services endpoint

What You Get

• Confirmed booking with a unique booking ID
• Payment confirmation with transaction details
• Full itinerary including all segments and passenger assignments
• Provider confirmation reference number

Key Features

• Idempotent: Returns the existing booking (HTTP 200 + data[0].message) if one already exists for the given prebookId. Transient book failures are retried in place without exposing a terminal failure status. Concurrent duplicate requests while a book is in progress return HTTP 409 (45035).
• Payments: Stripe uses transactionId from prebook or attach-services after SDK confirmation; credit line uses CREDIT with server-side eligibility checks; CREDIT_CARD charges the provided card immediately — send card details in billingInfo via https://pci-book.liteapi.travel (contact the team to enable this on your API key); ACC_CREDIT_CARD charges the card saved on your account immediately, with no card details in the request (in sandbox it simulates the booking without a charge)
• Provider confirmation: Finalizes the reservation on the provider side

Quick Start

Required fields: prebookId (from POST /flights/prebooks), payment with method and, for Stripe, transactionId

Tip: If you used POST /flights/prebooks/{prebookId}/services to attach ancillary services, use the new transactionId from that response, not the original prebook transactionId.

Vouchers

A voucher applied at prebook (or attach-services) is checked again when you book, before anything is charged or booked. The booking is refused with HTTP 400, and nothing is charged, when since then the voucher was deactivated or deleted (45088), its validity period no longer includes the booking time (45089), its discount was changed so that it no longer gives the amount applied, or its minimum spend was raised above the price (45090), its usage limit was reached by other bookings (45091), or its remaining budget no longer covers the amount applied (45092). The amount applied is never changed at book: prebook again to apply the voucher as it is now. A booking retried in place after its voucher was already charged is not checked again.