Travel technology has a steeper domain floor than most verticals a development partner might claim to cover. GDS response normalization, NDC's shift toward airline-controlled offers, IATA/BSP settlement rules, and PCI DSS 4.0.1 payment requirements aren't things a generalist software team picks up mid-project without real cost to your timeline and your data security. This checklist gives travel brands, OTAs, and agencies a structured way to vet a development partner before committing to a booking platform, aggregation layer, or reservation system build.

Before you start

  • [ ] Define scope precisely: booking engine, GDS/NDC aggregation layer, reservation system, or a full OTA platform — domain depth requirements differ by scope
  • [ ] Identify which suppliers you need connectivity to (specific GDSs, NDC-enabled airlines, hotel/ground transport APIs) before evaluating partners
  • [ ] Decide whether IATA/BSP accreditation handling is your responsibility or something the partner needs to architect around
  • [ ] Set a non-negotiable list on security and compliance certifications given payment data exposure

1. Domain fluency: GDS, NDC, and supplier integration

  • [ ] Ask the partner to explain, unprompted, how they normalize differing response schemas between GDSs like Amadeus and Sabre — genuine experience shows here, marketing language doesn't
  • [ ] Confirm hands-on NDC integration experience, since NDC's XML-based, airline-controlled offer model requires materially different handling than legacy EDIFACT/GDS fare filings
  • [ ] Ask how they handle multi-supplier aggregation — flights, hotels, ground transport — and how conflicting availability or pricing data gets reconciled
  • [ ] Request a reference project with a supplier mix similar to yours, not just "travel experience" in general terms
  • [ ] Confirm their approach to caching and real-time pricing — stale fare data is a common failure mode in poorly built aggregation layers

2. Payment security and PCI DSS 4.0.1

  • [ ] Confirm PCI DSS 4.0.1 compliance specifically — the updated standard has requirements (like authenticated scanning and expanded MFA) that older-standard experience doesn't cover
  • [ ] Clarify which PCI DSS requirements the partner fulfills versus which remain your responsibility under a shared-responsibility model
  • [ ] Ask about tokenization and hosted payment field approaches to minimize your own PCI scope
  • [ ] Confirm secure authentication practices for supplier API access — OAuth, encryption in transit, and role-based access controls

3. IATA, BSP, and regulatory fluency

  • [ ] Ask whether the partner has built systems that integrate with IATA's Billing and Settlement Plan (BSP) reporting and remittance flows
  • [ ] Confirm understanding of accreditation requirements relevant to your business model, even if accreditation itself is your responsibility, not theirs
  • [ ] For India-focused platforms, confirm familiarity with relevant consumer protection and data regulations (DPDP Act) alongside travel-specific rules

4. IP ownership and code practices

  • [ ] Confirm IP vests immediately upon creation and belongs to you from the moment code is written, not on final payment
  • [ ] Ask whether you get full commit history and repository access at handoff, or only a final deliverable
  • [ ] Clarify ownership of any custom normalization logic or supplier-mapping layer — this is often the most valuable and hardest-to-replace IP in a travel platform
  • [ ] Confirm documentation standards for API integrations and reservation logic transfer with the code

5. Delivery, support, and vendor stability

  • [ ] Ask about their process for handling supplier API changes — GDS and NDC endpoints evolve, and outdated integrations break bookings
  • [ ] Confirm support SLAs for production incidents, especially around peak booking periods and fare-related outages
  • [ ] Get references from travel clients of comparable scale and supplier complexity
  • [ ] Confirm the team's continuity — travel integrations built by a rotating cast of contractors tend to accumulate undocumented quirks fast

Red flags

  • Partner can't explain GDS response normalization specifically, only "we've done travel projects"
  • No clear PCI DSS 4.0.1 (not the older 4.0 or 3.2.1) compliance posture
  • Vague or evasive answers about who owns supplier-mapping and normalization code after the engagement
  • No experience with NDC despite it becoming standard for airline distribution
  • References can't speak to supplier complexity or peak-load performance

How to use this

Score finalist partners against sections 1–4 with a technical evaluator present, not just procurement — domain fluency in GDS/NDC and payment security is hard to assess from a sales deck alone. Weight IP ownership terms heavily; in travel platforms, the normalization and supplier-mapping layer is frequently the most defensible asset you build.

Vetting a travel technology partner on GDS/NDC fluency and PCI DSS 4.0.1 readiness — not just a portfolio — is exactly the kind of due diligence Syslabs helps travel brands run, and the API integrations and payment architecture work that follows once a partner is chosen.