Flyenzo Flight Booking Platform Enhancements

@AnumFatima210

Hi, I went through your project details and understand what you're looking to achieve. I'd be interested in working with you on this. Based on the requirements you've shared, I can handle the project from start to completion while keeping the work aligned with your expectations, timeline, and desired outcome. My approach is straightforward: first, I'll make sure the requirements and expected deliverables are clear. Then I'll complete the work in structured stages, share progress along the way, incorporate your feedback, and deliver the final work after everything has been reviewed. Before we begin, I have a couple of questions about your requirements that will help me understand the scope more accurately. Feel free to message me so we can discuss the details and determine the best way to move forward. Best regards, Anum

@melikatfz

Hello, 1. Have you tried using Redis Streams for real-time updates? 2. Are the Stripe add-ons currently integrated with any third-party APIs? Excited to enhance Flyenzo's features! For the live cabin map, I'll ensure real-time updates are seamless across sessions. Handling the seat selection optimistically will guarantee a smooth user experience. Let's connect to discuss the timeline and details. Looking forward to mapping out the next steps with you! Feel free to message me anytime for a quick chat.

@shayankhan333

Seat-lock races usually come from broadcasting after the Lua ack instead of inside the same round trip, so I'll push updates via a Postgres LISTEN/NOTIFY channel keyed off the lock hash, with an in-memory fallback when Redis is down. For add-ons I'll pass them as Stripe line items and reconcile in the existing webhook using the PNR as idempotency key. Refunds pro-rate against fare rules, then write an audit row. I can jump in today. 1. Are fare rules stored in Postgres or fetched from a GDS? 2. Multi-passenger add-ons: one line item per pax, or grouped? Cheers Shayan

@longngoc2307

==== Hi - Truong here ==== “REAL-TIME SEAT MAP + IDEMPOTENT STRIPE FLOWS” — you need the three remaining booking workflows finished without introducing race conditions or duplicate charges/refunds. I’d handle seat updates through Redis pub/sub or a realtime channel while keeping the existing Lua lock as the source of truth. Add-ons would be persisted first and mapped to separate Stripe line items, with webhook processing made idempotent. For cancellations, I’d keep fare-rule calculation and Stripe refund creation transactional with a Postgres audit record, then cover the full flow with Playwright. Do you already have the fare-rule structure and refund rules defined in the current codebase? Looking forward to work with you.

@juanestebana17

Hello! I understand you need focused production-ready enhancements for Flyenzo’s live cabin map, ancillary add-ons, and automated cancellation refunds. I’ve spent the last several years solving exactly this type of problem in Node.js and web development projects, with strong JavaScript, PostgreSQL, and Stripe work on transactional booking flows, real-time seat locking, idempotent checkout/webhook handling, and audit-safe refund pipelines. I’m ready to get started, and I’m confident we can make this project a success and deliver it to a high standard. I’m committed to ensuring everything is completed professionally, efficiently, and exactly according to your requirements. Best regards!

@albertc1996

Your architecture and stack requirements are clear. For the live cabin map, I will refine the optimistic UI transitions while ensuring multi-session state synchronization remains atomic alongside your Redis Lua locking mechanism, including clean local fallbacks. For ancillaries, I will integrate dynamic add-on selection directly into the booking flow and format them as distinct line items in Stripe Checkout while preserving webhook idempotency. Finally, I will automate the pro-rated cancellation refund pipeline via Stripe's API and record complete audit trails in Postgres via Drizzle ORM. I build robust TypeScript full-stack applications with strict API integrations and real-time state handling, backed by thorough testing. Relevant full-stack work: https://www.freelancer.com/u/albertc1996/14046021 https://www.freelancer.com/u/albertc1996/14004383 I can review the seat-lock Lua script and existing webhook handlers immediately to begin milestone implementation.

@Cruz1217

The live cabin map can suffer from brief seat‑lock conflicts when two users pick the same seat at the same moment. I'll swap the Redis poll for server‑sent events, delivering updates instantly, and add an optimistic UI that reverts if the Lua lock fails. A simple fallback that reads from a local in‑memory store when Redis is down will keep local development running smoothly. A common mistake is handling refunds in a manual step, which often leaves the database out of sync with Stripe. I'll compute pro‑rated amounts from the fare rules, call Stripe's refund API, and write a record to Postgres so the admin view stays accurate. I'm ready to start right away and will keep the existing ESLint and Prettier rules intact.

@rofeald

Hi, I can add the live cabin map updates, in-flow add-ons, and automated cancellation refunds to Flyenzo without disturbing your existing booking, Clerk, Redis, or Stripe flows. For the cabin map, I’d keep the Redis Lua lock model and add optimistic React state plus a server-action reconciliation layer so seat changes sync cleanly across sessions. In local dev, I’d add a Redis-disabled fallback path that still exercises the UI and lock handling without breaking the app. For add-ons, I’d persist meal/lounge/priority selections in Postgres via Drizzle, calculate prices server-side, and pass them to Stripe as separate line items while keeping webhook handling idempotent. For refunds, I’d implement fare-rule proration, create Stripe refunds automatically, and store a full audit trail in Postgres for the admin dashboard. I’ll cover unit tests for the pricing/refund logic and a Playwright end-to-end flow for seat changes, add-ons, and cancellation. I’m available in Egypt timezone and ready to move forward and deliver the required solution.

@amadorjay

Hi there, The hard part is not just implementing new features; it's ensuring they work flawlessly with existing systems. For the live cabin map, achieving real-time updates across sessions while maintaining the integrity of your current Redis setup will be crucial. For the ancillary add-ons, the challenge lies in dynamically pricing options while keeping the idempotency intact for Stripe transactions. Automating the cancellation refunds will also require careful handling of fare rules to ensure compliance and a clear audit trail. Can you clarify if there are specific fare rules that need to be incorporated for the refund process? Looking forward to discussing the details in chat.

@MusouDigital

Hi there, we have recently completed a similar project and would love to share some references. Your Flyenzo Flight Booking Platform enhancements sound right up our alley and we would love to exceed your expectations. I understand the importance of a live cabin map that provides smooth real-time updates, along with dynamic ancillary add-ons that integrate seamlessly with Stripe. Automating cancellation refunds while maintaining a clear audit trail is crucial for enhancing user experience and operational efficiency. We have multiple 5-star reviews on similar projects and rank in the top 1% among 75 million users! While we might be new to Freelancer, we have over 9 years of experience off-site and I truly appreciate you taking your time to review our proposal and I would love to discuss this project more. Kind regards, Trichelle

@abdf2010

Hi, I am a professional web developer and I can do this project "Flyenzo Flight Booking Platform Enhancements", I have 5 years of experience in web development. I have done many projects like this. I can do this job for you. I can start right now. Please contact me. Thanks

@ridwaan6254

that is close to my daily stack, so let me skip the introductions and talk about where a booking flow that is already live tends to hurt next. the failure that matters is between stripe and the reservation. checkout succeeds, then pnr generation fails or times out, and now the customer has paid and holds no booking. it is rare enough to feel unlikely and frequent enough to happen, and it is the one support ticket that costs you a customer permanently. so the questions i would ask first: is the booking created idempotently against the payment intent, does a stripe webhook retry produce one booking or two, and what reconciles a paid intent with no pnr? second, times. flight times are local at each airport, not utc, and a flow that normalises everything to utc and renders it back will eventually show someone the wrong departure. worth checking how you are storing and displaying those before it becomes support volume rather than a bug. third, holds. if inventory or price is reserved during checkout, what releases it when someone abandons at the card screen. on the app router specifically, server actions plus redis caching is where stale reads creep in after a mutation. what is the next thing you actually want built, and is any of the above already handled?