Client project
FreeToGo: an end-to-end flight booking platform
Flight search, booking, payments and refunds for a UK travel business, across a website, a React Native app, an admin back office and a Kotlin API.
The booking website is live at freetogotravels.com. The React Native app is built but has not been published to the stores.
- Client
- FreeToGo Travels, United Kingdom
- Sector
- Travel
- Industry
- Travel & Booking
- Period
- 2024 to 2026
- Platforms
- Web, Android, iOS, Admin web panel, REST API
- Key figures
- 4apps: website, mobile app, admin and API
- 2airline content APIs integrated
Apps people use
- Web
- Android
- iOS
- Admin web panel
Backend and business rules
- Kotlin
- Spring Boot
- Spring Security + JWT
- PostgreSQL
- Flyway
- Redis
- Resilience4j
Connected services
- Stripe
- Duffel API
- Amadeus API
- Azure
The problem
FreeToGo Travels needed one platform where travellers could search live airline content, book and pay for flights, and later request refunds, on the web or on their phone. The team running the business needed a back office to manage bookings, ticketing, payments, refunds and customer queries without switching between supplier portals.
What we built
We built the whole platform: a customer website in React and TypeScript, a React Native app, an admin back office, and a Kotlin and Spring Boot API that connects to airline content suppliers and Stripe. The API holds the booking, payment and refund logic, so the website, the app and the admin all work from the same rules.
Key features
- One-way, return and multi-destination flight search with filters and fuzzy search
- Live airline content through the Duffel API, later extended with Amadeus for pricing, ordering, ticketing, seat maps and branded fares
- Stripe payments with 3D Secure, Apple Pay and Google Pay, plus a retry-payment flow
- Refund workflow with status tracking, a scheduler and automatic refunds
- Configurable commission and pricing engine
- Prices shown in the traveller's currency, based on IP geolocation
- Ticket PDFs and transactional emails for bookings, refunds and one-time passcodes
- Customer accounts with OTP sign-up, bookings list, refund requests and account deletion
- Admin dashboard with booking status charts and geographic maps
- Admin tools for single and bulk ticket issuing, payments, refunds, users and queries, with an audit log
Technology stack
The main technologies used in this project.
- Kotlin
- Spring Boot
- Spring Security + JWT
- PostgreSQL
- Flyway
- Redis
- Resilience4j
- React
- TypeScript
- Vite
- Redux Toolkit
- Ant Design
- React Native
- Stripe
- Duffel API
- Amadeus API
- GitHub Actions
- Azure
Our role
NinjaNext designed and built the backend API, the customer website, the admin back office and the React Native app, and set up the CI/CD pipelines. Our founder is the main author across all four codebases.
Challenges and how we handled them
Keeping bookings and payments in step
A flight order and its payment are two separate systems. Webhooks from the airline supplier and from Stripe, plus scheduled status checks, keep the booking and the payment in agreement, and the admin sees the raw supplier data when something needs a person.
Refunds without manual chasing
Refunds move through defined states, from requested to paid out. A scheduler moves them forward and emails the customer at each step, so staff only handle exceptions.
Changing supplier without breaking the product
Supplier code sits behind its own service layer, which let us add Amadeus alongside the original Duffel integration without rewriting the booking flow.
What the client said
NinjaNext Technologies helped us turn our travel business idea into a working digital platform. The team understood our requirements, paid attention to the details, and worked on the booking flow and payment integration. Communication was clear throughout the project, and we appreciated their focus on building a solution that could grow with our business.
Let's build it
Planning something similar?
Tell us about your project. If it is close to FreeToGo, we will explain what we would reuse, what we would do differently and what to decide first.