# Kickoff Checklist {% hint style="info" %} 💬 **Need help?** If you're stuck, ask Eva on ATRIP for instant diagnostics. Ask Eva {% endhint %} Use this page in the first integration call. Its goal is simple. Leave the meeting with the main flow, ownership, and launch path agreed. {% hint style="info" %} Need a shorter customer pre-read first? Use [Top Questions for Partners](https://resources.atriptech.com/api-document/troubleshooting-and-support/faqs/top-questions-for-partners). {% endhint %} ### 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 {% stepper %} {% step %} ### Confirm the commercial and product fit Clarify whether Atlas is the main shopping source or the final booking and pricing layer. {% endstep %} {% step %} ### Choose the booking flow Decide whether the standard search flow or Get Offer flow is the main implementation path. {% endstep %} {% step %} ### Confirm payment and ticketing design Align deposit or VCC usage, polling logic, and final state handling. {% endstep %} {% step %} ### Confirm post-booking ownership Agree how refund, change, schedule change, and urgent cases will be handled. {% endstep %} {% step %} ### Confirm launch path Agree sandbox scope, UAT expectations, and go-live prerequisites. {% endstep %} {% endstepper %} ### 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](https://resources.atriptech.com/api-document/readme/booking-overview) * [Get Offer](https://resources.atriptech.com/api-document/readme/booking-overview/get-offer) * [Verify](https://resources.atriptech.com/api-document/readme/booking-overview/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](https://resources.atriptech.com/api-document/readme/booking-overview/seats-and-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](https://resources.atriptech.com/api-document/troubleshooting-and-support/faqs/atlas-api-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](https://resources.atriptech.com/api-document/readme/booking-overview/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](https://resources.atriptech.com/api-document/troubleshooting-and-support/faqs/atlas-api-post-ticketing) * [Webhook Overview](https://resources.atriptech.com/api-document/readme/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](https://resources.atriptech.com/api-document/readme/quick-start) * [UAT Validation](https://resources.atriptech.com/api-document/readme/quick-start/uat-submission-guide) * [Production Go-Live](https://resources.atriptech.com/api-document/readme/quick-start/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](https://resources.atriptech.com/api-document/troubleshooting-and-support/faqs/before-integration) * [Top Questions for Partners](https://resources.atriptech.com/api-document/troubleshooting-and-support/faqs/top-questions-for-partners) * [FAQs](https://resources.atriptech.com/api-document/troubleshooting-and-support/faqs) * [Booking Overview](https://resources.atriptech.com/api-document/readme/booking-overview) * [Post-booking Overview](https://resources.atriptech.com/api-document/readme/post-booking-overview)