How do I set up an NDC API platform for booking flow orchestration with our reservation system?

Setting up an NDC API platform for booking-flow orchestration with your reservation system is mostly an integration architecture problem: you need a layer that can translate between NDC shopping/booking messages and your reservation/PSS/OMS capabilities, while keeping pricing, offer integrity, seat/inventory control, payments, and ticketing synchronized.

Here’s a practical way to approach it.

---

1) Define the target architecture

A typical setup has these components:

• Client channels
  • Web, mobile app, call center, OTA, corporate booking tools
• NDC API gateway / orchestration layer
  • Handles authentication, throttling, versioning, routing
  • Owns booking flow state
• NDC service adapters
  • Translate NDC messages to internal reservation system actions
  • Separate adapters for shopping, pricing, order creation, servicing, ticketing, etc.
• Offer / order state store
  • Keeps track of transient shopping sessions, offers, and order status
• Reservation system / PSS
  • Source of truth for inventory, PNR, ticketing, ancillary availability, seat maps, etc.
• Payment services
  • PSP integration, 3DS, fraud checks, refunds, tokenization
• Event bus / async workflow engine
  • Useful for ticketing completion, schedule changes, cancellations, reissues, notifications
• Observability stack
  • Logs, traces, metrics, audit trails

A good principle:
NDC APIs should orchestrate the customer journey, while the reservation system remains the operational source of truth.

---

2) Choose the booking flow you want to support

NDC booking orchestration usually covers:

1. Shopping
   • Search offers for origin/destination/date/passengers
2. Pricing / offer validation
   • Reconfirm availability and fare rules
3. Ancillary selection
   • Seats, bags, meals, priority services
4. Order creation
   • Convert offer into a bookable order/PNR
5. Payment
   • Pay by card/wallet/BNPL/corporate account
6. Ticketing / fulfillment
   • Issue ticket(s), EMDs, confirmations
7. Post-booking servicing
   • Change, cancel, refund, rebook, add ancillaries

Start by deciding whether your first release supports:

• shopping + book + pay + ticket, or
• shopping + order create + payment later, or
• a more advanced order management model.

---

3) Map NDC concepts to your reservation model

You’ll need a translation layer between NDC and your internal system.

Common NDC entities:

• Offer
• OfferItem
• Order
• OrderItem
• ServiceDefinition
• Passenger
• Price
• PaymentInfo
• Change / cancel requests

Typical internal mappings:

• Offer → fare quote / priced itinerary / temporary shopping record
• Order → PNR / booking record / order ID
• OfferItem → flight segment + ancillaries + fare components
• Price → fare, taxes, fees, surcharges, discounts
• OrderItem → booked segment, seat, baggage, service
• PaymentInfo → payment authorization/capture record
• Ticketing status → ticket coupon / EMD issuance state

Important:
Decide early whether your platform is PNR-centric, order-centric, or hybrid. Many airlines use a hybrid because the reservation system may still be PNR-based even when exposing NDC-style orders.

---

4) Design the orchestration flow

A good pattern is a state machine or workflow engine for each booking.

Example flow:

A. Shopping

• Client calls SearchOffers
• Orchestrator sends requests to shopping adapter
• Adapter queries reservation/inventory/pricing
• Response returns one or more offers
• Store offer snapshot with TTL

B. Offer validation

• Client selects an offer
• Orchestrator validates the offer is still valid
• Reprice if needed
• Lock inventory if your system supports it

C. Ancillary selection

• Seat map / baggage / services added
• Update offer and price
• Hold total amount and constraints

D. Order creation

• Create booking / PNR / order in reservation system
• Persist correlation IDs
• Write order state to internal store

E. Payment

• Authorize or capture payment
• On success, continue fulfillment
• On failure, cancel/expire holds as needed

F. Ticketing / fulfillment

• Trigger ticket issuance
• Confirm ticket numbers / EMDs
• Notify customer/channel

G. Post-booking

• Expose retrieval, cancel, refund, exchange, service add-ons

Use idempotency keys for all write operations, especially:

• Create order
• Take payment
• Ticket issuance
• Cancel/refund

---

5) Integrate with the reservation system safely

Your reservation system likely has constraints:

• Limited APIs
• Batch-heavy processing
• Legacy host commands
• Hard transaction boundaries
• Inventory concurrency issues

To avoid problems:

Use an anti-corruption layer

Do not let NDC messages directly couple to legacy host logic.
Build adapters that:

• Validate input
• Normalize data
• Convert response formats
• Map errors cleanly

Control concurrency

For shopping and booking:

• Use offer TTL
• Recheck availability before commit
• Use soft holds or seat inventory locks where possible
• Handle race conditions when multiple shoppers target the last seat

Make writes transactional

For booking and payment:

• Use a workflow with compensating actions
• If payment succeeds but ticketing fails, retry ticketing or trigger manual intervention
• If order creation succeeds but payment fails, release the booking or let it expire according to rules

---

6) Implement the required API capabilities

At minimum, your NDC platform should expose:

Shopping

• Offer search
• Offer revalidation
• Offer details
• Calendar/low-fare search if needed

Booking

• Order create
• Order retrieve
• Order cancel
• Payment initiate/confirm
• Ticketing status

Servicing

• Add ancillaries
• Seat selection
• Change order
• Refund or void
• Order notifications/webhooks

Supporting features

• Authentication and authorization
• PNR/order correlation
• Currency and tax handling
• Error normalization
• Audit trail

If you’re following IATA NDC, align with the version your partners need, such as:

• NDC 18.2, 21.3, or later depending on ecosystem compatibility

---

7) Decide how pricing will work

Pricing is often the hardest part.

You need rules for:

• Fare construction
• Taxes and fees
• Currency conversion
• Ancillary pricing
• Promotions and discounts
• Corporate agreements
• Fare rule validation
• Time-bound offer validity

Best practice:

• Return a priced offer snapshot with a validity window
• Reprice on order creation
• Support price guarantee logic if your business allows it
• Keep pricing consistent across shopping, checkout, and ticketing

---

8) Handle payment and fulfillment explicitly

A booking flow usually has these payment patterns:

• Auth then capture
• Immediate capture
• Pay later
• Mixed tender: card + voucher + credit account

You should design:

• Payment initiation API
• Secure tokenization
• 3DS/strong customer authentication
• Fraud screening hooks
• Payment reversal/refund support

For fulfillment:

• Ticketing may be synchronous or asynchronous
• If asynchronous, publish a status callback/webhook
• Record all fulfillment identifiers for downstream servicing

---

9) Build for reliability and observability

This is critical in booking systems.

Reliability patterns

• Idempotency keys
• Retries with backoff
• Circuit breakers
• Dead-letter queues for failed async steps
• Timeout budgets per step
• Compensating transactions

Observability

Track:

• Offer search latency
• Offer conversion rate
• Booking success/failure rates
• Payment success rate
• Ticket issuance success rate
• Inventory mismatch rate
• Partner/channel performance

Add:

• Correlation IDs across all services
• Immutable audit logs
• Reconciliation reports between NDC platform and reservation system

---

10) Secure the platform

You’ll need:

• OAuth2 / OpenID Connect or client credentials for B2B partners
• mTLS for trusted partners if required
• Scope-based authorization
• PCI DSS controls for payment data
• Data encryption at rest and in transit
• PII masking in logs
• Role-based access for customer service agents
• Rate limiting and abuse detection

---

11) Testing strategy

Test at multiple layers:

Unit tests

• Message mapping
• Pricing logic
• Validation
• Error transformations

Integration tests

• Reservation system adapters
• Payment gateway
• Ticketing/fulfillment

Contract tests

• NDC schema compliance
• Partner-specific message compatibility
• Backward compatibility between versions

End-to-end tests

• Search → book → pay → ticket
• Change → reprice → settle difference
• Cancel → refund
• Seat selection and ancillary purchase

Simulation tests

• Inventory exhaustion
• Payment failure
• Ticketing timeout
• Retry storms
• Host outage scenarios

---

12) A phased implementation plan

Phase 1: Foundation

• API gateway
• NDC request/response model
• Adapter framework
• Auth, logging, correlation IDs
• Search and pricing only

Phase 2: Book and pay

• Offer validation
• Order creation
• Payment integration
• Booking confirmation

Phase 3: Fulfillment

• Ticketing
• EMDs/ancillaries
• Notifications

Phase 4: Servicing

• Cancel, refund, change
• Post-booking ancillaries
• Irregular operations support

Phase 5: Optimization

• Caching
• Performance tuning
• Analytics
• Partner certification automation

---

13) Recommended implementation pattern

A practical architecture is:

• API Gateway
• NDC Orchestrator
  • Booking workflow engine
  • State store
  • Idempotency service
• Adapters
  • Shopping adapter
  • Pricing adapter
  • PNR/order adapter
  • Payment adapter
  • Ticketing adapter
  • Ancillary adapter
• Reservation system
• External services
  • Payment provider
  • Email/SMS
  • Fraud
  • Loyalty
• Event bus
  • BookingCreated
  • PaymentAuthorized
  • TicketIssued
  • BookingFailed
  • RefundCompleted

This keeps the NDC layer clean and lets you replace or upgrade reservation components without breaking partners.

---

14) Common pitfalls to avoid

• Exposing the legacy reservation system directly to partners
• Not using idempotency for booking/payment
• Treating shopping offers as permanent
• Ignoring currency/tax mismatches
• Mixing synchronous and asynchronous fulfillment without clear state handling
• Not modeling failure recovery
• Poor alignment between offer TTL and inventory hold duration
• Incomplete audit/reconciliation

---

15) What to ask internally before starting

Answer these first:

1. Is the reservation system PNR-based, order-based, or hybrid?
2. What NDC version must be supported?
3. Which flows are in scope for MVP?
4. How is inventory controlled today?
5. What is the payment model?
6. Is ticketing synchronous or asynchronous?
7. Which post-booking functions are required?
8. What latency and availability targets do you need?
9. What compliance requirements apply?
10. Which channels/partners must be certified first?

---

16) Practical MVP recommendation

If you want a realistic first release:

• Support:
  • Search offers
  • Revalidate offer
  • Create order
  • Take payment
  • Ticket booking
  • Retrieve order
• Keep:
  • One payment method initially
  • One currency if possible
  • Limited ancillaries
  • Basic cancellation only
• Add:
  • Logging, idempotency, reconciliation from day one

That gives you a working NDC booking platform without overbuilding.

---

If you want, I can also help with one of these next steps:

1. a reference architecture diagram for the NDC platform,
2. a detailed API flow for search → book → pay → ticket, or
3. a data model mapping between NDC objects and your reservation system.