The weeks before launch decide how smooth the first months of a flight booking website will be. Most problems that reach real customers, such as wrong prices, payments without tickets and missing emails, can be caught with structured testing. Use this checklist with your development team before you go live.
Search and results
- One-way, return and multi-city searches work on desktop and mobile.
- Domestic and international routes return results from every connected supplier.
- Searches with children and infants return correct fares.
- Filters and sorting work and update instantly.
- No results and supplier timeout messages are clear and helpful.
Pricing
- Markups, discounts and service fees apply correctly by airline, route and channel.
- Displayed prices include all taxes and fees.
- Promo codes work, expire on time and cannot be stacked unless intended.
- Currency conversion, if used, matches your chosen rates.
Booking and ticketing
- Bookings create a valid PNR with each supplier.
- Passenger name validation follows airline rules.
- Fare revalidation catches price changes before payment.
- Tickets are issued automatically after payment, and the e-ticket number is stored.
- Ticketing time limits are tracked, and unpaid bookings are released.
Payments
- Every payment method works in the live gateway environment, not just the test one.
- Failed and abandoned payments do not create tickets.
- Payment success with ticketing failure triggers an alert and a refund or retry flow.
- Refunds reach the original payment method.
After-sales
- Cancellations follow fare rules and calculate refunds correctly.
- Date change requests reach the operations team.
- Customers can view and download their booking from their account.
Communication
- Booking confirmation, e-ticket, cancellation and refund emails are sent and look right on mobile.
- SMS or WhatsApp notifications, if used, arrive promptly.
- Your contact details and support hours are visible on every page.
Security and compliance
- The whole site uses HTTPS.
- Card data is handled only by the payment gateway, never stored on your servers.
- Admin accounts use strong passwords and limited permissions.
- Privacy policy, terms and cancellation policy pages are published.
Performance and SEO
- Pages load quickly on a mid-range phone over mobile data.
- Important pages have unique titles and descriptions.
- An XML sitemap is submitted to Google Search Console and Bing Webmaster Tools.
- Analytics and conversion tracking record searches, bookings and revenue.
Operations readiness
- Your team knows how to handle failed tickets, refunds and schedule changes.
- Supplier support contacts are documented.
- Daily reconciliation of bookings and payments is planned.
Run a soft launch first
Before announcing the website, run a soft launch with a small group of real customers or staff bookings. Issue real tickets on low-cost routes, process real refunds and check every email. Soft launches surface problems that test environments miss, such as differences between supplier test and live systems.
Frequently asked questions
How long should pre-launch testing take?
It depends on the number of suppliers and payment methods. Plan at least a couple of weeks for structured testing and a soft launch, and do not compress this time to meet a marketing date.
Who should do the testing?
Developers test functions, but operations and finance staff should test the workflows they will use every day: refunds, queues, reports and reconciliation.
What should we monitor in the first week?
Watch failed bookings, payment-to-ticket mismatches, search errors by supplier and customer support requests. Fix patterns quickly while volumes are still small.
Supplier and account checks
- Live credentials are configured for every supplier, and test credentials are removed.
- Supplier certification, where required, is complete and signed off.
- Your deposit or credit with each supplier is sufficient for launch-week volumes.
- Ticketing office IDs and queue settings are correct in each GDS.
- Payment gateway settlement account details have been verified with a small test transaction.
These checks are easy to overlook because they sit outside the code, yet a missing deposit or wrong office ID can stop all ticketing on day one.
After launch: the first 30 days
Launch day is not the end of testing. In the first month, review every failed booking and every customer complaint, and look for patterns: one supplier failing more than others, a payment method with high drop-off, or emails landing in spam. Fixing these early, while volumes are small, prevents them from becoming expensive habits.
Key takeaways
- Test every supplier, payment method and edge case in the live environment.
- Pay special attention to the payment-to-ticketing handover.
- Prepare your operations team as carefully as the software.
We test every flight portal against a launch checklist like this one. Learn more about our flight website development process.
