Kickoff Checklist

Use this checklist in the first integration call to align flow choice, payment, ticketing, post-booking, and launch readiness.

Use this page in the first integration call.

Its goal is simple.

Leave the meeting with the main flow, ownership, and launch path agreed.

Need a shorter customer pre-read first?

Use Top Questions for Partners.

What this meeting should achieve

By the end of kickoff, both sides should agree on:

• the booking flow to implement

• the price refresh point before booking

• the payment mode by business case

• the ticketing status handling model

• whether seat or baggage must be supported before purchase

• who owns refund and change follow-up

• what is required before UAT and go-live

Recommended meeting order

1

Confirm the commercial and product fit

Clarify whether Atlas is the main shopping source or the final booking and pricing layer.

2

Choose the booking flow

Decide whether the standard search flow or Get Offer flow is the main implementation path.

3

Confirm payment and ticketing design

Align deposit or VCC usage, polling logic, and final state handling.

4

Confirm post-booking ownership

Agree how refund, change, schedule change, and urgent cases will be handled.

5

Confirm launch path

Agree sandbox scope, UAT expectations, and go-live prerequisites.

Section 1: Business and system fit

Ask these first:

• Is Atlas your main shopping source?

• Or do you already have your own shopping engine?

• Do you need Atlas mainly for final bookable price confirmation?

• Do you need one flow for all airlines, or selective routing by carrier?

Decision to record

Write down one of these as the main role of Atlas:

• primary shopping and booking layer

• final pricing and booking layer

• selective supplier in a multi-source system

Section 2: Booking flow

Choose the main path.

Standard search path

Use this when Atlas is your main shopping source.

Main chain:

1. search.do

2. verify.do

3. order.do

4. pay.do

5. queryOrderDetails.do

Get Offer path

Use this when the target itinerary is already known.

Main chain:

1. getOffers.do

2. order.do

3. pay.do

4. queryOrderDetails.do

Questions to settle

• Which path is the default production path?

• When do you refresh price before booking?

• Will your system block stale pricing after long delays?

• Will you support both flows or only one?

See:

• Booking Overview

• Get Offer

• Verify

Section 3: Pricing integrity

This is usually the highest-risk topic.

Align on these rules:

• search result is not the final booking promise

• verify or Get Offer should be used close to booking time

• long delays increase failure and mismatch risk

• latest verified or offered price is the source of truth for order creation

Questions to settle

• What is the latest point where price must be refreshed?

• What happens if the user returns after a delay?

• Will markup be applied before or after final refresh?

• Which value is shown to the user when price changes?

Section 4: Fare content and ancillaries

Set expectations early.

Questions to settle

• Do you need fare family display?

• Do you need baggage upsell before booking?

• Do you need seat map before booking?

• Do you need post-ticketing baggage or seat sales?

• Can ancillary lookup stay optional in the first release?

Important rule

Do not force ancillary queries into the base flow unless they are required.

See Seats & Baggage.

Section 5: Payment model

Confirm the primary payment path before build starts.

Main options

• Deposit

• VCC pass-through

Questions to settle

• Which payment mode is the default?

• Will payment mode differ by airline?

• Does the client provide VCC cards?

• What happens when VCC is unavailable for a specific order?

• How will refund expectations be shown to operations teams?

Important rule

Atlas does not issue VCC cards.

See Payments.

Section 6: Ticketing and booking status

Treat ticketing as asynchronous.

Questions to settle

• Will the client poll after pay.do?

• Which state is treated as final success?

• When will the client surface airline PNR to agents or users?

• How will duplicate payment be prevented?

• What identifiers are stored for follow-up?

Minimum identifiers to retain

• routingIdentifier

• sessionId or OfferId

• orderNo

• pnrCode

• airline PNR when available

See Query Order.

Section 7: Post-booking operations

This part is often under-scoped.

Questions to settle

• Who submits refunds?

• Who follows up delayed refunds?

• How are changes requested?

• Who monitors schedule changes?

• What is the process for urgent departure-day cases?

Important rules

• refund path depends on payment mode

• change handling is routed through ATRIP service requests

• webhook should not be the only reconciliation source

See:

• Post-booking

• Webhook Overview

Section 8: Delivery plan

End the kickoff with delivery expectations.

Questions to settle

• Which scope is included in sandbox first?

• What is required before UAT starts?

• Which UAT track applies?

• Who prepares evidence?

• What must be ready before production launch?

See:

• Quick Start

• UAT Validation

• Production Go-Live

Final output of the kickoff

Do not end the meeting with only open discussion.

Leave with a written decision log for:

• chosen booking flow

• pricing refresh rule

• payment mode

• polling rule

• ancillary scope

• post-booking ownership

• UAT owner

• go-live prerequisites

Related pages

• Before Integration

• Top Questions for Partners

• FAQs

• Booking Overview

• Post-booking Overview