doc_id: “FLYMAX-06-PRD-FLIGHT-BOOKING-PLATFORM-PRD-V3” project_name: “FlyMax V2.0” title: “Flight Booking Platform — PRD v3.0” doc_type: “PRD” category: “Product Requirements” version: “1.0.0” status: “active” scope: “valid” lifecycle_state: “active” created: “2026-03-09” updated: “2026-03-09” author: name: “George Joseph” role: “Technical Lead / Solution Architect” modified_by:

name: “George Joseph” role: “Technical Lead / Solution Architect” date: “2026-03-09” approved_by:
name: “” role: “” date: “” next_review_date: “2026-03-09”

Flight Booking Platform — PRD v3.0

Document Type: Product Requirements Document
Product: Flight Booking Platform
Version: 3.0
Status: Draft for Review / Governing Baseline Proposal
Date: 2026-03-09
Owner: Product / Architecture / Program Office
Supersedes: PRD v2.0 (redirect-led baseline), Product Model v2.x references

📕DOWNLOAD PDF 📗DOWNLOAD DOCX

1. Executive Summary

PRD v3.0 defines the product as a Verteil-powered, direct-booking, flight retail and servicing platform with platform-owned checkout, payment orchestration, booking lifecycle continuity, credit governance, unified support, and role-based operations for Consumers, Agents, and Admin/Ops teams.

This document replaces the older redirect-first baseline. The governing user journey is no longer Search → Compare → Redirect. It is now:

Discover → Search → Compare → Validate / Reprice → Capture traveler details → Collect payment or reserve credit → Book → Confirm / Ticket → Manage booking → Service / Support → Reconcile

PRD v3.0 establishes:

the authoritative product model for current scope
the current-vs-later scope partition
detailed feature requirements by domain
portal responsibilities by role
payment, settlement, credit, and reporting requirements
direct-booking support and servicing requirements
parity-grade search and merchandising expectations
non-functional requirements, release gates, and open decisions

The product is flight-first, Verteil-first, and operations-aware. It is not an affiliate-only meta-search engine and it is not a redirect-led business model.

2. Document Intent and Use

2.1 Purpose

This PRD is intended to align Product, Engineering, QA, Design, Operations, Finance, Support, Partnerships, and Security on a single governing definition of the product.

2.2 How to use this PRD

This document should be used as the primary baseline for:

implementation planning
UI/UX scope definition
backend domain modeling
integration sequencing
QA test planning
delivery phasing
UAT and go-live readiness
cross-functional approval and change control

2.3 Document philosophy

This PRD is intentionally detailed because the product is no longer a simple discovery layer. It owns transactional, operational, support, and finance-sensitive flows.

2.4 Scope precedence

If older artifacts conflict with this document, PRD v3.0 takes precedence for current planning.

3. Product Definition

3.1 Canonical product statement

The Flight Booking Platform is a Verteil-powered direct flight booking and servicing platform with:

on-platform checkout
payment gateway orchestration
booking and ticket lifecycle continuity
agent credit workflows
markup, promotion, and discount governance
unified support ticketing
auditability, reporting, and finance traceability

3.2 Product classification

The product shall be treated as:

a flight retail platform
a direct-booking orchestration platform
a B2C + B2B/B2B2C operating platform
an agent-enabled airline retailing platform
an operations-heavy booking and servicing product

The product shall not be framed as:

an affiliate-only meta-search engine
a pure redirect comparison site
a content-only travel discovery site
an airline inventory owner
a standalone OTA/GDS replacement

3.3 Product purpose

To provide a unified platform for flight search, booking, payment, booking management, servicing, support, and travel-seller operations without pushing users or agents into fragmented external flows.

4. Why v3 Exists

4.1 Problem with the old baseline

Earlier documents still encoded:

redirect-led booking completion
no direct booking or payment ownership
affiliate/ad-led monetization as the main model
servicing and support as limited or deferred

That baseline is no longer compatible with the clarified product direction.

4.2 What changed

The governing business and product model now includes:

direct booking through platform-controlled UX
payment collection inside the platform
Verteil-backed lifecycle support for booking and servicing
agent and sub-agent operations
credit, discount, and reconciliation logic
support case ownership by the platform
promotions and commercial governance in current scope

4.3 Why this is a major version change

This shift changes:

business model
operational ownership
liability and settlement exposure
persona model
portal requirements
data model boundaries
KPI design
support and finance obligations

5. Product Principles

Booking continuity over redirect fragmentation
Operational traceability over opaque workflows
Commercial governance over ad hoc pricing behavior
Role clarity over blended permissions
Supportability over feature-only thinking
Flight-first depth over shallow multi-vertical sprawl
Extensibility later without making future capabilities current dependencies
Trust and transparency over aggressive merchandising
Supplier-aware activation over fake universality
Financial visibility over hidden settlement behavior

6. Goals, Non-Goals, and Success Outcomes

6.1 Product goals

The platform should:

enable direct flight booking with platform-owned checkout
support both traveler and travel-seller distribution models
provide consistent booking management after payment
support governed agent credit and pricing controls
provide unified support across booking, payment, and credit workflows
deliver market-parity search and comparison UX
maintain finance-grade reporting and reconciliation visibility
remain extensible to more providers later

6.2 Current non-goals

The platform is not trying in this version to:

become a multi-vertical travel super-app
depend on AI for baseline product operation
launch multiple providers on day one
provide universal live chat as a mandatory MVP feature
build consumer-native mobile apps in the initial release
cover hotels/cars as core scope

6.3 Strategic outcomes

The intended outcomes are:

higher search-to-booking conversion than redirect-led experiences
stronger customer trust via owned checkout and support continuity
controlled B2B economics through credit and markup governance
better finance and operational visibility than a pure referral model
a credible path toward broader supplier coverage later

7. Scope Model

7.1 Current scope now

Current scope includes:

Verteil integration for search, book, retrieve, modify, cancel, refund, and reschedule
Consumer, Agent, and Admin/Ops role model
booking management
payment gateway integration
credit management
markup logic
discount management, including corporate / co-operate discounts
SSO and MFA/2FA
reports
CDC / webhooks
notifications
audit logs
profile management
caching and performance controls
logs, analytics, bug reporting
provider/service management
airline/flight visibility/configuration where supported
currency management and localization preferences
external knowledge-base content surfaces
promotions, SEO, and ads management
unified support ticketing
charter/custom flight inventory as a governed module
parity-grade search and merchandising

7.2 Later by default

The following are deferred by default:

multiple providers beyond the initial Verteil-led supply path
AI capabilities

7.3 Not valid exclusions anymore

The following are not accepted as default exclusions:

direct booking
payment processing
booking servicing
SSO
promotions
corporate discounts
support operations

7.4 Supplier-dependent / gated scope

Some in-scope capabilities may still be:

supplier-dependent
market-dependent
commercially gated
ops-gated
approval-gated

This applies especially to:

private and corporate fares
payment modes by market
held booking or pay-later paths
ancillary availability
change/refund depth
charter/custom inventory
notification channels by region

8. Personas and Stakeholders

8.1 External personas

P1. Consumer / Traveler

Needs to search, compare, pay, book, manage bookings, and receive support without leaving the platform.

P2. Agent / Travel Seller

Needs organization-aware booking, customer handling, pricing control within allowed boundaries, credit usage, reporting, and support.

P3. Agent Sub-User

Needs limited scoped access for search, booking, customer handling, ticket/support access, and reporting according to agent organization permissions.

8.2 Internal personas

P4. Super Admin / Platform Operator

Manages platform-wide settings, providers, security, promotions, booking oversight, and governance.

P5. Finance / Reconciliation Team

Tracks payment state, settlement state, credit exposure, refunds, and financial exceptions.

P6. Support / Operations Team

Handles booking issues, payment issues, refund/change cases, incidents, supplier coordination, and escalations.

P7. Commercial / Partnerships Team

Owns supplier onboarding, commercial rules, corporate pricing boundaries, and promotional configuration.

P8. Security / Compliance Team

Owns SSO, MFA policy, audit review, incident controls, and sensitive path protection.

9. Jobs To Be Done

9.1 Consumer JTBD

Help me find viable flight options quickly.
Help me understand total price, baggage, restrictions, and implications before I pay.
Let me book without unnecessary redirects.
Let me see my booking and payment status after checkout.
Let me get help if something goes wrong.

9.2 Agent JTBD

Let me search and book efficiently for travelers.
Let me manage my team and organization activity.
Let me operate within approved credit and discount rules.
Let me export booking and financial reports.
Let me raise support or finance cases tied to a booking.

9.3 Admin JTBD

Let me control providers, pricing, discounts, credits, and promotions centrally.
Let me monitor booking and payment health.
Let me reconstruct what happened through logs and audits.
Let me approve sensitive actions without ambiguity.

10. Target Market

10.1 Primary market

Travel agents, consolidators, sub-agents, and reseller businesses that need:

searchable airline inventory
agent-focused booking tools
organization and sub-user control
credit-led purchasing support
markup and discount governance
exportable operational and financial reports

10.2 Secondary market

Consumers who need:

strong search and comparison UX
transparent pricing
on-platform payment
post-booking continuity
support continuity

10.3 Internal market

Platform operations, finance, support, and commercial teams requiring:

dashboards and reports
approvals and audit trails
issue reconstruction
payment and credit visibility
supplier governance

11. Business and Commercial Model

11.1 Core commercial model

The platform operates as a direct-booking transaction platform.

11.2 Consumer payment model

The end user pays the platform through an integrated payment gateway.
The platform records payment intent, authorization, capture, failure, refund, reversal, and booking outcome states.
Payment state must be linked to booking state and visible to finance and support.

11.3 Agent credit model

Agents maintain a platform credit balance or approved credit arrangement.
Credit top-up, approval, reservation, consumption, release, adjustment, and visibility are core platform concerns.
Credit events must be auditable and visible to finance.

11.4 Settlement model

Depending on supplier/commercial arrangements, settlement may use:

BSP / airline-linked settlement routes
credit-based platform settlement
direct payment rails supported by supplier flows
pay-later constructs where contractually and operationally permitted

11.5 Revenue model

Revenue may include:

markup on bookings
service fees
negotiated pricing margin where allowed
commercial program economics
approved promotional / boosted placement revenue

11.6 Revenue model exclusions

The following are no longer the central governing model:

redirect-led affiliate monetization
click-out attribution as the primary revenue path
ads as the main business model

12. Supply and Platform Ownership Model

12.1 Initial provider strategy

The product launches with Verteil as the primary supply and servicing backbone.

12.2 Later provider strategy

The platform architecture must remain extensible for additional providers, but multi-provider rollout is not current-baseline scope.

12.3 What Verteil is expected to support

Where enabled by supplier/source conditions, the product assumes Verteil-backed support for:

shopping/search
booking and ticketing
ancillaries
payment-linked workflows
cancellation and refund workflows
itinerary modifications and penalty/fare difference handling
post-ticket servicing
agent/sub-agent oriented workflows
pricing / rule engine support
reporting-oriented back-office flows

12.4 What the platform owns

The platform owns:

product UX
search presentation and merchandising
portal access and role controls
consumer and agent identity
payment gateway integration
platform-side credits and finance controls
support case management
promotions, SEO, and content surfaces
reporting, audit, and operations views

13. Experience Model

13.1 Experience layers

The platform has three main experience layers:

Consumer web experience
Agent workspace
Super Admin / internal ops experience

13.2 Experience principles

The experience should be:

transparent
low-friction
role-aware
localization-aware
secure
supportable
auditable
promotion-capable without breaking trust

13.3 Table-stakes parity expectations

The base product must include:

one-way / round-trip / multi-city search
passenger and cabin selection
airport autocomplete and nearby-airport assistance
flexible date / calendar pricing support
filters and sorting
fare breakdown and baggage visibility
booking management after checkout
notifications and alerts
profile/history/saved-trip continuity where relevant
centralized payment and booking confirmation visibility

14. Core User Journeys

14.1 Consumer journey

Discover → Search → Compare → Inspect details → Select offer → Reprice / validate → Enter traveler details → Pay → Book → Confirm / ticket → Manage booking → Service / support if needed

14.2 Agent journey

Login → Search for traveler → Compare → Apply governed commercial configuration → Validate fare/pricing → Book under credit/payment rules → Manage booking → Export / report → Raise support or finance case if needed

14.3 Admin journey

Configure platform → Manage users/agents/providers → Govern pricing, discounts, credits, and promotions → Monitor health and incidents → Review reports and audits → Resolve escalations

14.4 Support journey

Ticket created → Linked to booking/payment/credit record → Categorized and prioritized → Internal/external threaded communication → Resolution / escalation → Closure with audit trail

15. Capability Domains

15.1 Search and discovery

Includes:

one-way, round-trip, multi-city, and open-jaw where supported
passenger mix and cabin selection
airport/city autocomplete
nearby-airport assistance
flexible dates / calendar support
route and destination discovery surfaces
progressive result loading
localization and currency-aware search context

15.2 Results, comparison, and merchandising

Includes:

side-by-side comparison
total price visibility
fare breakdown
baggage/fare-rule visibility where available
branded fares where available
filters for stops, airline, timings, duration, layovers, airports, price range
sorting by price, duration, departure, arrival, and best value
promotion-aware merchandising
corporate / discount eligibility indicators where applicable

15.3 Offer validation and repricing

Includes:

pre-book validation
currency/payment-aware repricing where required
mismatch detection
user-facing changed-offer handling
availability-change recovery flows

15.4 Checkout and payment orchestration

Includes:

traveler and contact capture
fare acceptance and policy confirmation
payment gateway initiation
payment authorization and capture tracking
booking creation only after successful payment conditions or approved credit rules
failure, retry, and recovery flows
transactional notifications

15.5 Booking, order, and ticket lifecycle

Includes:

book
retrieve
modify
cancel
refund request / visibility
reschedule/change
booking confirmation and ticket status
order timeline/history
passenger data updates where supported
post-ticket ancillary addition where supported

15.6 Commercial controls

Includes:

markup logic for consumer and agent contexts
pricing rules
discount management
coupon / promo code support
corporate / negotiated pricing support
approval boundaries
commercial rule audit trail

15.7 Credit and financial governance

Includes:

credit top-up requests
approval / rejection
reservation against booking attempts
consumption on successful booking
release on failure/cancel paths
adjustments and corrections
finance-facing reconciliation and exposure tracking

15.8 Provider, airline, and service management

Includes:

provider enable / disable
supplier configuration and credentials governance
airline visibility/configuration where supported
source/channel activation rules
health status by provider/source

15.9 User, agent, and organization management

Includes:

local auth
agent organization model
agent sub-user model
RBAC and portal segmentation
profile management
traveler data support
account status governance
SSO support
MFA / 2FA support

15.10 Notifications and communications

Includes:

transactional emails
booking notifications
payment success/failure notifications
refund/change/cancellation notifications
support ticket update notifications
notification preference management
SMS / WhatsApp / push where approved later

15.11 Support and case management

Includes:

ticket creation by user, agent, and admin/support
categories for booking, payment, refund, change, credit, account, and technical issue
priorities and SLA handling
threaded communication
internal notes
attachments
linkage to booking/order/payment/credit records
audit trail of support actions

15.12 Reports, audit, and reconciliation

Includes:

booking reports
sales reports
agent/date-wise exports
payment and settlement visibility
refund/change visibility
credit ledger reporting
promotion performance reporting
operational KPI reporting
immutable audit logs
health dashboards and incident visibility

15.13 Promotions, ads, and growth surfaces

Includes:

boosted airlines
boosted routes
boosted offers
ads/promo placements within approved surfaces
campaign configuration
prioritization and labeling rules
performance reporting

Includes:

route pages
city / destination pages
travel content / blog / static pages
schema markup and sitemap
external knowledge base for visa / travel prerequisites / guidance content
publication controls

15.15 Security, compliance, and operational controls

Includes:

SSO integration
MFA / 2FA policies
role-sensitive auth controls
audit log integrity
sensitive admin action controls
secrets/config governance
incident visibility
payment/security posture alignment

15.16 Performance and caching

Includes:

Redis / CDN strategy
cache invalidation/freshness policies
search session performance handling
supplier timeout resilience
health monitoring
logging, analytics, and bug reporting

15.17 Charter / custom / rented flight inventory

This remains current scope as a governed optional module, not a universal default inventory assumption. It must be modeled as:

supplier-dependent
commercially gated
ops-reviewed
separately surfaced from standard scheduled inventory where necessary
subject to dedicated quotation, confirmation, servicing, and support rules

16. Portal Model

16.1 Super Admin portal

Must support:

user management
markup management
credit approval flows
booking management
provider/service management
airline/flight visibility/configuration
localization and currency configuration
discount configuration
notification management
security management
external KB configuration
health monitoring
payment gateway configuration
promotions and ads management
report exports
audit access

16.2 Agent portal

Must support:

sub-user management
markup management within allowed scope
credit requests and visibility
booking management
reports and exports
localization and currency preferences
discount request/configuration within allowed scope
notification preferences
profile management
support case creation and tracking

16.3 User portal

Must support:

user profile
booking management
saved preferences
localization and currency preferences
notification preferences
support case creation and tracking
booking history and continuity features

17. Functional Requirements

Format note: Each FR is treated as MVP/current-scope unless explicitly marked as conditional or later.

FR-01 — Flight Search Session Management

Objective: Enable fast, flexible search initiation and progressive result retrieval.

Actors: Consumer, Agent, Agent Sub-User
Must support:

one-way, round-trip, multi-city
passenger mix and cabin selection
origin/destination autocomplete using city and airport entities
nearby-airport assistance
flexible dates / calendar context
currency and locale context
search session creation with expiry
progressive retrieval/polling model

Validation rules:

valid airport/city identifiers only
adult >= 1
infants <= adults
return date >= departure date
supported passenger count caps configurable by policy

Acceptance criteria:

all declared search modes work end-to-end
invalid combinations are blocked with explicit error messages
progressive results support partial loading before completion timeout

FR-02 — Fare Aggregation, Normalization, and Deduplication

Objective: Convert supplier responses into a canonical internal offer model.

Must support:

Verteil-first search execution
canonical itinerary/segment/fare representation
multi-offer handling
duplicate cluster resolution
timeout-tolerant partial result return
supplier error isolation

Acceptance criteria:

no malformed offer is rendered
partial supplier failure does not collapse the full search experience
duplicate itineraries preserve price/source distinctions where commercially relevant

FR-03 — Search Results, Filters, Sorting, and Comparison

Objective: Provide parity-grade comparison UX.

Must support:

results list with side-by-side option comparison
filters for price, stops, airline, timings, duration, layovers, airports
sorting by price, duration, departure, arrival, best value
total price display
base fare / tax / fee breakdown
baggage visibility where available
fare-rule visibility where available
clear source/provider labeling

Acceptance criteria:

filter state is stable and reversible
all displayed prices include currency and total payable amount
empty states are deterministic and recoverable

FR-04 — Offer Validation and Repricing

Objective: Prevent stale or misleading offers from reaching checkout.

Must support:

pre-book validation
repricing when required by source conditions
availability mismatch handling
price-change disclosure
user decision flow for accepted changed price or declined booking

Acceptance criteria:

price/availability changes are surfaced clearly before booking commitment
changed offers never silently proceed without user confirmation

FR-05 — Traveler, Contact, and Booking Input Capture

Objective: Capture complete, valid bookable traveler data.

Must support:

adult/child/infant traveler capture
contact details capture
identity/travel-document fields where required by route/source
saved traveler support by role and permission
validation for mandatory fields and traveler-type rules
fare-rule/policy acknowledgement

Acceptance criteria:

the platform blocks incomplete or invalid bookable payloads
traveler data can be reviewed before final commit

FR-06 — Consumer Checkout Flow

Objective: Enable on-platform direct booking for consumers.

Must support:

review step before payment
payment initiation through gateway
payment pending / success / failure handling
booking request execution after eligible payment state
confirmation state with booking reference visibility
post-payment recovery if booking creation fails
clear separation of payment failure vs booking failure vs partial success

Acceptance criteria:

user never sees ambiguous terminal states
booking outcome and payment outcome remain linked and visible

FR-07 — Agent Booking Flow

Objective: Support organization-aware travel-seller booking under commercial controls.

Must support:

customer-on-behalf booking
sub-user activity tracking
booking under credit or approved payment rules
price construction under allowed markup/discount policies
organization-level booking visibility
role-sensitive traveler/profile persistence

Acceptance criteria:

agent users cannot exceed their pricing/credit permissions
all bookings are attributable to organization and acting user

FR-08 — Payment Orchestration and State Management

Objective: Maintain auditable end-to-end payment state.

Must support:

payment intent creation
authorization and capture tracking
failure and retry handling
refund and reversal state linkage
settlement state visibility
reconciliation identifiers linking payment to booking/order/credit

Acceptance criteria:

finance and support can reconstruct payment state from audit/history
payment status changes emit usable downstream events

FR-09 — Booking Creation, Confirmation, and Ticket Visibility

Objective: Provide reliable booking continuity after checkout.

Must support:

booking creation against validated offer
booking confirmation state
ticket issuance visibility where available
booking/order timeline
customer-facing reference visibility
agent-facing reference and organization context

Acceptance criteria:

post-book confirmation states are visible in portal and notifications
booking timeline records major milestones

FR-10 — Booking Retrieval and Management

Objective: Let users and agents access booking continuity after purchase.

Must support:

retrieve/view booking
traveler and contact visibility
ticket status visibility
history/timeline view
role-based access control for who can view what
booking search within portal based on role permissions

Acceptance criteria:

each role sees only its permitted booking set
key booking milestones are available without contacting support

FR-11 — Modify / Reschedule / Cancel / Refund Flows

Objective: Support post-booking servicing as a first-class product concern.

Must support:

modify booking where supported
reschedule/change requests and flows
cancellation requests and flows
refund request / refund visibility
penalty and fare-difference display where available
servicing status tracking
constraint disclosure when source capability is limited

Acceptance criteria:

unsupported servicing actions fail with clear reason and next step
supported actions create traceable cases/events

FR-12 — Ancillary Handling

Objective: Support ancillary awareness and additions where available.

Must support:

ancillary display at shopping or servicing stages where provided
post-ticket ancillary addition where supported
ancillary-related payment linkage
ancillary visibility in booking timeline

Acceptance criteria:

ancillary availability is never implied when source data does not support it
ancillary charges remain auditable

FR-13 — Markup and Pricing Rules

Objective: Support governed price construction without hidden logic.

Must support:

supplier/base fare + taxes/fees + markup + discount effect composition
consumer vs agent rule separation
rule scope by role, organization, channel, route, or fare class where approved
effective-date control
reversible audited changes

Acceptance criteria:

all pricing rule changes are attributable to actor/time/version
unauthorized users cannot alter active commercial rules

FR-14 — Discount, Coupon, and Corporate Pricing

Objective: Support modern commercial discounting without policy ambiguity.

Must support:

coupon / promo code discounts
platform promotions
corporate / co-operate discounts
negotiated/private fare eligibility indicators where supported
agent-requested discount workflows
admin-approved discount controls

Acceptance criteria:

discounts are role-governed and auditable
conflicting rules resolve through deterministic precedence

FR-15 — Credit Ledger and Financial Governance

Objective: Treat credit as a governed financial domain, not a loose balance number.

Must support:

credit top-up requests
approval/rejection
reservation against booking attempt
consumption upon booking success
release on eligible failure/cancel paths
manual adjustment and correction
organization and actor-level ledger visibility
exposure reporting

Acceptance criteria:

every credit movement produces a ledger event
reserved vs available vs consumed balances are distinguishable

FR-16 — Provider, Airline, and Service Activation Management

Objective: Provide controlled supplier and channel governance.

Must support:

provider enable/disable
credential/config lifecycle
health status visibility by provider/source
source/channel activation rules
airline visibility/configuration where supported
future extensibility without breaking current contracts

Acceptance criteria:

admin can disable problematic sources without redeploying product code
provider state changes are audited

FR-17 — Admin Portal and Operational Control Center

Objective: Provide a complete internal control plane.

Must support:

dashboards
booking oversight
payment gateway configuration
provider and commercial management
discount and promotion management
user and agent management
report exports
audit access
incident and health visibility

Acceptance criteria:

sensitive actions require proper role/approval boundaries
dashboards expose current operational health and backlog exceptions

FR-18 — Agent Workspace and Sub-User Management

Objective: Support B2B/B2B2C operations without creating admin-level power leakage.

Must support:

sub-user creation and role assignment inside allowed boundaries
booking activity visibility by sub-user
allowed markup and discount handling
credit request workflows
organization report access
support case access within org scope

Acceptance criteria:

agent scope never crosses organization boundary
sub-user permissions are inheritable but revocable

FR-19 — User Profile, Preferences, and Saved Data

Objective: Reduce repeat friction while keeping role-aware data ownership.

Must support:

profile management
traveler profile / saved traveler where allowed
notification preferences
localization/currency preferences
saved searches / saved trips / history where enabled
booking history continuity

Acceptance criteria:

users can update preferences without affecting unrelated accounts
saved data follows access and deletion policy

FR-20 — Notifications and Communications

Objective: Ensure important state changes are communicated.

Must support:

booking confirmation notifications
payment success/failure notifications
refund/change/cancellation notifications
support ticket updates
notification preference management
email as baseline channel
later channel extensibility for SMS / WhatsApp / push

Acceptance criteria:

all critical transactional flows emit a user-visible communication event
promotional messages respect opt-in / preference settings

FR-21 — Unified Support Ticketing

Objective: Provide a single support system for Consumers, Agents, and Admin/Support Ops.

Must support:

ticket creation by user, agent, and admin/support
categories: booking, payment, refund, cancellation, change, credit, account/access, technical issue, dispute
statuses: open, in progress, waiting for customer, waiting for supplier, resolved, closed
priority + SLA
threaded conversation
attachments
internal vs external notes
role-based visibility
ticket linkage to booking/order/payment/refund/credit entities
audit trail of support actions

Acceptance criteria:

support ticketing is available in current scope and not deferred
support history is reconstructible from linked entities and thread history
live chat remains optional and later, not a dependency for MVP

FR-22 — Reports, Audit, and Reconciliation

Objective: Make operations and finance measurable.

Must support:

booking reports
payment reports
sales reports
refund/change reports
agent reports
credit/ledger reports
provider performance reports
support SLA/volume reports
audit/event logs
exportability for admin and agent roles where allowed

Acceptance criteria:

each core business domain has at least one auditable report surface
exports are permission-aware and traceable

FR-23 — Identity, RBAC, SSO, and MFA

Objective: Enforce role-sensitive identity and access controls.

Must support:

local auth
SSO integration
role-based access control
agent organization segmentation
MFA / 2FA support
sensitive admin path protection
access auditability

Acceptance criteria:

admin-sensitive paths require stronger auth posture than standard user journeys
role resolution is deterministic and testable

FR-24 — CDC, Webhooks, and Operational Eventing

Objective: Keep booking, payment, and servicing state synchronized across internal systems.

Must support:

booking state events
payment state events
refund/change/cancel events
downstream webhook publishing or ingestion where needed
idempotent event handling
event auditability
replay/recovery strategy for failed deliveries

Acceptance criteria:

critical business state transitions are evented
duplicate deliveries do not produce double-processing

FR-25 — Promotions, Boosted Inventory, and Ads Governance

Objective: Support current-scope growth surfaces without degrading trust.

Must support:

boosted airlines, routes, and offers
approved promo/ad placements
labeling rules
prioritization rules
admin campaign controls
performance reporting
suppression / review rules to avoid misleading surfaces

Acceptance criteria:

paid or boosted surfaces are visibly identifiable where required
merchandising never suppresses mandatory price/trust disclosures

Objective: Provide discoverability and self-service information surfaces.

Must support:

route pages
destination/city pages
content hub/blog/static pages
structured metadata/schema
sitemap support
admin content governance
external KB content for visa/travel prerequisites/guidance

Acceptance criteria:

content publication is admin-governed
KB and SEO surfaces do not interfere with transactional correctness

FR-27 — Currency, Localization, and Preference Management

Objective: Support regional usability without requiring full multilingual rollout.

Must support:

currency preference
locale preference
role-sensitive defaults
admin configuration for supported currencies and localizations
consistent currency use across search, checkout, booking, and reports

Acceptance criteria:

price display and settlement views avoid ambiguous currency mixing
unsupported locales fail gracefully to configured defaults

FR-28 — Charter / Custom Flight Inventory Module

Objective: Represent non-scheduled inventory without contaminating standard-flow assumptions.

Must support:

separate surfacing from scheduled inventory where appropriate
quotation / confirmation / servicing / support rules specific to charter inventory
commercial gating and approval controls
ops review path before activation

Acceptance criteria:

charter/custom inventory activation is explicit, governed, and auditable
standard-flight UX is not degraded when charter module is disabled

18. Business Rules and Policy Requirements

18.1 Role boundaries

Consumers may access only self-owned bookings and support cases.
Agents may access organization-scoped bookings, support cases, and reports.
Agent sub-users inherit org scope but only within assigned permissions.
Super Admin has platform-wide visibility subject to security policy.
Finance and Support may receive scoped operational visibility based on function.

18.2 Rule precedence

When multiple pricing or discount rules apply, the system shall resolve conflicts using documented precedence:

hard validation/supplier constraints
approved corporate/private fare rules
approved organization-level rules
platform-wide discount/promotion rules
default markup/service fee logic

18.3 Auditability

The following actions require audit logging:

provider activation/deactivation
pricing rule changes
discount rule changes
credit approvals and adjustments
payment state overrides or manual interventions
booking servicing actions
support ticket state changes
access/role changes
security setting changes

18.4 Support ownership

Because the platform owns booking, payment, and credit workflows, support ticketing is mandatory in current scope. Chat may be added later, but ticketing is not optional.

19. Data Model Boundaries

19.1 Core logical entities

The product assumes the following core aggregates:

User
AgentOrganization
AgentSubUser
Role / Permission
Profile
Traveler
SearchSession
Offer / Itinerary / Fare
Booking / Order
Ticket / BookingStatusTimeline
PaymentTransaction
RefundCase / ChangeCase
CreditAccount / CreditLedgerEntry
DiscountRule / PromotionRule / CorporatePricingRule
Provider / Airline / ServiceChannel
NotificationPreference / NotificationEvent
SupportTicket / SupportMessage / SupportAttachment
AuditLog
HealthSnapshot / Incident
ExternalKBArticle / ContentPage

19.2 State-bearing entities

The following must be stateful and historically traceable:

SearchSession
Booking / Order
PaymentTransaction
CreditLedgerEntry
RefundCase / ChangeCase
SupportTicket
Provider health state

19.3 Minimum timeline expectations

At minimum, the system shall keep event/timeline visibility for:

booking lifecycle
payment lifecycle
support lifecycle
credit lifecycle
admin-sensitive configuration changes

20. Integration Requirements

20.1 Verteil integration

The product shall integrate with Verteil-backed capabilities for:

search
book
retrieve
modify
cancel
refund
reschedule/change
ancillary availability where supported

20.2 Payment integration

The platform shall integrate with one or more payment gateways for:

payment initiation
authorization
capture
failure handling
refund initiation or state sync where applicable

20.3 Notification integration

The platform shall support:

email as current mandatory baseline
later optional integration with SMS / WhatsApp / push channels

20.4 Identity integration

The platform shall support:

local auth
SSO integration
MFA / 2FA mechanisms

20.5 Analytics and observability integration

The platform shall expose and/or emit:

application logs
health metrics
analytics events
bug/incident tracking hooks
webhook/event integrations for operational sync

21. Reporting and KPI Model

21.1 KPI philosophy

The KPI model shall reflect owned transaction outcomes, not redirect metrics as the primary governing layer.

21.2 Proposed business KPI families

search-to-booking conversion
payment success rate
booking/ticket issuance success rate
offer reprice/mismatch rate
refund/change turnaround visibility
support SLA and resolution quality
credit utilization and exception rate
finance reconciliation accuracy
promotion effectiveness without trust degradation
platform uptime and supplier health

21.3 Proposed technical KPI targets

These are proposed initial targets for implementation planning and should be validated during delivery planning:

page load: ≤ 3.0s p75 LCP on mid-tier mobile
API response (non-search): ≤ 500ms p95
search time-to-first-results: ≤ 800ms p95
search time-to-stable-results: ≤ 2.5s p95
uptime: ≥ 99.9% monthly

21.4 Proposed operational dashboards

Dashboards should support:

booking health
payment health
refund/change backlog
credit exposure
support volume and SLA
supplier health
promotion performance
audit and incident visibility

22. Non-Functional Requirements

22.1 Performance

non-search API p95 ≤ 500ms
search first chunk p95 ≤ 800ms
search hard cutoff p95 ≤ 2.5s
page load ≤ 3.0s p75 LCP on mobile

22.2 Capacity / concurrency

Proposed planning baseline:

burst search session creation support
concurrent active search sessions in the low five figures
route-budgeted supplier fanout controls
stateless API scale-out support behind CDN / load balancer

22.3 Reliability

uptime ≥ 99.9%
supplier failure isolation
retry for idempotent search flows only
idempotent webhook/event processing
circuit-breaker behavior for failing upstreams
graceful degradation when upstream capability is partially unavailable

22.4 Security

OWASP-aligned review before go-live
TLS in transit
encrypted storage/backups
RBAC for all privileged surfaces
MFA mandatory for sensitive admin paths
secrets/config governance
audit logging for sensitive actions

22.5 Compliance

privacy-aware data handling
deletion/anonymization workflow for applicable personal data requests
payment-security posture aligned with selected payment architecture
role-sensitive access to financial/support data
retention policy defined before go-live

22.6 Observability

The system shall emit structured logs and metrics for:

search latency and errors
supplier latency and timeout rates
booking state changes
payment state changes
support SLA breaches
credit movements
provider health
incident and exception tracking

22.7 Supportability

The product shall be operable by internal support teams without database-only reconstruction as a default mechanism.

23. Risks, Assumptions, and Constraints

23.1 Product risks

supplier-dependent servicing depth may vary
payment and credit flows increase liability and operational load
promotions can degrade trust if poorly labeled
corporate/private fare logic may become commercially complex
charter inventory may require non-standard flows
regional channel differences may complicate auth and notifications

23.2 Design constraints

the product must remain operable with Verteil-first supply
the system must preserve a clean extension path for later providers
AI must not be a hard dependency for baseline operation
support and finance traceability must exist from day one of direct booking operations

23.3 Implementation assumptions

a selected payment gateway will be approved for current markets
Verteil-backed lifecycle capabilities will be activated per contract and source support
role model and approval logic will be finalized before build freeze
reporting/export requirements will be reviewed by finance and operations before UAT

24. Delivery Phasing

24.1 Phase 1 / Current release baseline

Phase 1 should deliver:

direct booking baseline with Verteil-first supply
search and comparison parity
consumer checkout
agent booking under governed rules
booking management
support ticketing
payment and credit traceability
Admin / Agent / User portals
notifications, reports, audit, and core SEO/content surfaces

24.2 Later-by-default phase

Later scope should focus on:

multiple providers beyond Verteil
AI capability layers

24.3 Feature activation via gates

Some current-scope modules may launch disabled or partially enabled until:

commercial approvals exist
supplier support is confirmed
ops playbooks are ready
finance and support sign-off is complete

Examples:

corporate/private fares
pay-later paths
charter inventory
some servicing actions
non-email notification channels

25. Release Readiness and UAT Gates

25.1 Go-live gates

Before go-live, the following must be complete:

in-scope features implemented and tested
payment and booking state linkage verified
booking management visible in portal
support ticketing operational
admin controls and audit logs operational
provider credentials configured for live route set
documentation delivered
rollback approach rehearsed

25.2 UAT conditions

UAT is complete only when:

each role can execute its critical journey
transaction states are not ambiguous
support can reconstruct real incidents
finance can inspect booking-linked financial movement
commercial controls behave deterministically
parity-grade search UX is functional on supported browsers/devices

25.3 Operational handover requirements

The delivery team must provide:

role matrix
support workflow guide
payment and booking state map
credit lifecycle guide
incident/health dashboard guide
data export/report guide

26. Open Decisions Requiring Formal Approval

Merchant-of-record and settlement design
Final operating model for consumer payments, supplier settlement, and financial liability handling.
Payment methods by market
Which payment methods are in MVP versus later by region.
Credit policy
Top-up, approval, reservation, release, and exposure thresholds.
Corporate/private fare activation
Which markets, providers, and user groups may access them.
Servicing depth at launch
Which modify/cancel/refund/reschedule flows are fully self-service versus routed through support.
Notification channel mix
Email only at launch or approved inclusion of SMS / WhatsApp / push.
SSO activation timing
Mandatory at launch for some roles or phased after MVP.
Charter/custom inventory activation
Whether module ships dark/launched later or partially enabled.
Support operating model
SLA, staffing hours, escalation policy, and supplier coordination playbook.
Data retention policy
Final durations for search, bookings, audit logs, support artifacts, and financial records.

27. Source Basis

This PRD v3 is synthesized from:

Product Model v3.0
PRD v2.0 and older redirect-era scope documents
parity and feature research documents
support ticketing decision notes
Verteil corporate and commercial materials
scope and approval register materials

It intentionally resolves legacy contradictions by treating the direct-booking product model as authoritative.

28. Final Governing Statement

PRD v3.0 defines the Flight Booking Platform as a Verteil-powered, direct-booking, flight retail and servicing platform for Consumers, Agents, and Admin/Ops teams, with platform-owned checkout, payment, booking lifecycle continuity, markup/discount/credit governance, SSO and security controls, promotions, support ticketing, reporting, auditability, and flight-platform table-stakes required for market parity; only Multiple Providers and AI capabilities are deferred by default.

Document ID: FLYMAX-06-PRD-FLIGHT-BOOKING-PLATFORM-PRD-V3
Canonical Version: 1.0.0
Lifecycle: Active
Scope: Valid
Source of Truth: docs/
Related Change Ticket:
Last Reviewed On: 2026-03-09
Next Review Due: 2026-03-09

Approval Sign-off

Role	Name	Status
Product Owner		Pending
Technical Lead / Solution Architect	George Joseph	Pending
Engineering Lead		Pending
Commercial / Operations		Pending

Document Lineage

Supersedes:
Superseded By:

Change Log

1.0.0 (2026-03-09) - Header/footer standardized to FlyMax documentation playbook.