# Travel booking supplier evidence

Research date: 9 November 2026. Sources below are official provider documentation. Public documentation establishes available capabilities, not approval for this business, a signed contract, accepted merchant status, guaranteed coverage, or quoted commercial terms. Recommendations are proposals. No live bookings, partner applications, or account creation were performed.

## Executive recommendation

Propose a narrow first release with Duffel flights, one lodging integration, and Viator activities subject to the required access. Prototype all journeys now; validate supplier access and payment settlement before promising automatic checkout. Build the product around explicit, item-level approval tied to exact supplier quotes. Expand comparison coverage only after proving that the first booking channel can issue, retrieve, cancel, refund, and support a booking.

The customer can have one product account. That does not mean there is one underlying supplier transaction, one merchant, or a universally reusable payment token. The product needs a payment and settlement design for each supplier, with a unified customer-facing ledger. An issuer authentication or supplier-specific CVC step can still interrupt checkout.

## Supplier matrix

| Provider | Verified capability | Access dependency | Proposed role |
| --- | --- | --- | --- |
| Duffel Flights | Search offers, refresh selected offers, create orders, receive airline booking reference | Test account is straightforward; live business verification and commercial/payment setup remain to be established | First flight provider |
| Duffel Stays | Search, retrieve room rates, obtain final quote, create booking; aggregated review score/count and a separate accommodation-review endpoint | Stays access must be requested; exact review-site attribution and display conditions need confirmation | First hotel provider to evaluate beside Duffel flights |
| Expedia Rapid Lodging | Shop, payment options, price check, booking, itinerary retrieval and cancellation links; up to 100 Expedia Group verified reviews per property request | Expedia partnership, integration approval, production enablement after site review, review display requirements | Review-focused alternative or later comparison provider |
| Booking.com Demand | Accommodation search and supported onsite booking/order management | Managed Affiliate Partner registration, signed agreement, account-manager access | Later hotel comparison/booking channel, conditional on acceptance |
| Amadeus Self-Service flights | Search, price, reserve, order management | Production ticket issuance through consolidator agreement; market and local requirements | Alternative flight provider where consolidator relationship is advantageous |
| Viator | Content-only affiliate, approved Full + Booking affiliate, or merchant integration | Higher levels require approval and certification | First activities provider to investigate |
| GetYourGuide | Content/availability tiers, and Masterbill onsite booking | Traffic/access criteria; booking access by partner manager, deposit and specialized agreement | Later channel, not assumed launch dependency |

## Flights and hotels

### Duffel

Duffel's flight guide describes offer search, refreshed offer details, passenger data, and order creation. Its managed-content example uses a Duffel balance; the guide tells the integrator to charge the customer before creating the order. Therefore customer payment and supplier settlement need separate states, including recovery when only one succeeds. [Flight guide](https://duffel.com/docs/guides/getting-started-with-flights).

Duffel Stays follows search, room-rate retrieval, final quote, then booking. A quote can become unavailable or change after search. The checkout must preserve the selected room, rate conditions, occupancy, and dates, then revalidate before purchase. The guide explicitly requires requesting Stays access. Its accommodation model includes an aggregated review score and count from multiple sources, and it exposes a separate paginated review endpoint with text, score, reviewer name and submission date. That review endpoint's documented record schema does not name the originating review site, so the exact source attribution, display, caching and AI summarization rules need written confirmation. [Stays guide](https://duffel.com/docs/guides/getting-started-with-stays), [accommodation schema](https://duffel.com/docs/api/v2/accommodation), [accommodation reviews](https://duffel.com/docs/api/v2/accommodation-reviews).

Duffel test tokens begin with `duffel_test_`. Duffel's Test Hotels are available only in test mode and require a search near `-24.38, -128.32`; that inventory cannot provide Istanbul hotel rates or rooms. TravelTiger therefore suppresses Stays searches made with a test token and labels the Istanbul pricing fields unavailable. Live Istanbul pricing remains an external dependency until Stays access and an activated live account are available. [Test mode](https://duffel.com/docs/api/overview/test-mode/duffel-airways), [Test Hotels](https://duffel.com/docs/guides/test-hotels), [Stays setup](https://duffel.com/docs/guides/getting-started-with-stays).

TravelTiger also accepts test tokens only for flight search. Duffel documents controlled test routes and notes that Duffel Airways test schedules and prices are not realistic. Keep every returned test result labeled as test data, never present it as a real fare, and never create an order in the pilot. The existing in-app shortlist saves an offer to the local draft only. [Test integration routes](https://duffel.com/docs/api/overview/test-your-integration), [test mode](https://duffel.com/docs/api/overview/test-mode/duffel-airways).

Expedia Rapid's verified guest review API returns up to 100 reviews from Expedia Group inventory, with ratings, text, dates, trip reason and traveler context. Review display requires disclosure that the review is verified as an Expedia Group booking, travelers may receive a voucher, and qualifying positive and negative reviews are published. This is useful source-specific evidence, but it is one provider's set and still needs partnership access and launch approval. [Guest Reviews API](https://developers.expediagroup.com/rapid/lodging/content/guest-reviews), [verified review requirements](https://developers.expediagroup.com/rapid/lodging/reference/verified-guest-reviews).

The services agreement distinguishes Pay By Card, Stays Payment Instruction, and Duffel Payments. Pay By Card and Stays Payment Instruction require preapproval. Stored-card consent is required. Some stay payment instructions may need a supplier payment link. Duffel Payments uses Stripe and credits the Duffel balance. These paths are commercially and technically different. [Services agreement](https://duffel.com/services-agreement).

For the direct supplier-card path, the hosted component supports saved cards but currently requires CVC input for each future transaction. It can also conduct 3DS. Store only provider card references and permitted display fields in the application. Do not promise completely unattended reuse of that saved card. [Card component](https://duffel.com/docs/guides/card-form-component-with-3dsecure).

Duffel documents special handling for booking creation: pending responses are not retries; uncertain 500/502 results must not be blindly retried. Capture the provider request ID and reconcile or escalate. Generic exponential retry middleware on purchase requests could duplicate commitments. Implement provider-specific retry rules, in addition to application-level purchase deduplication. [Response handling](https://duffel.com/docs/api/overview/response-handling).

### Expedia Rapid

Rapid Lodging supports room and rate shopping, payment-option discovery, price checks, and booking. A changed price comes back at price-check time. Store itinerary identifiers and retrieve the itinerary to confirm what was booked. [Lodging overview](https://developers.expediagroup.com/rapid/lodging).

Expedia requires a partnership and approval to integrate. Development credentials remain restricted until the integration passes site review and production access is enabled. This is an external dependency the AI cannot clear simply by completing code. [Setup](https://developers.expediagroup.com/rapid/setup), [Launch review](https://developers.expediagroup.com/rapid/setup/launch-requirements/launch-requirements?locale=en_US).

Rapid's launch requirements include traveler-facing payment timing, cancellation and property information, correct price display, and relevant payment-processing disclosures. Rates can involve different collection arrangements. Product design must show amounts paid now and later, including mandatory property charges. [Lodging requirements](https://developers.expediagroup.com/rapid/setup/launch-requirements/lodging-launch-reqs).

Strong customer authentication can introduce an issuing-bank challenge in a browser frame. Booking completion requires checking the authentication result. A single approve button can initiate the flow, but the interface needs an action-required state. [SCA integration](https://developers.expediagroup.com/docs/rapid/lodging/booking/psd2-regulation).

### Booking.com Demand

Demand access prerequisites include Managed Affiliate status, a signed agreement, Partner Centre access supplied by an account manager, and API credentials. These are prerequisites even for testing. [Prerequisites](https://developers.booking.com/demand/docs/getting-started/prerequisites).

The orders API has preview and create operations. Preview returns final pricing and payment options and generates an order token for creation. Store identifiers and implement supported post-booking functions separately. [Orders overview](https://developers.booking.com/demand/docs/orders-api/overview).

Current overview documentation distinguishes capabilities by service. Accommodations and cars support onsite booking flows; attractions are documented as content/search/redirect; transfers are beta search/redirect. Do not infer that every category can be booked merely because the shared orders API exists. [Demand overview](https://developers.booking.com/demand/docs/getting-started/overview).

Cross-site price comparison rights need explicit diligence. Legacy official usage rules restrict reuse of Booking.com content in comparison with other booking platforms. That legacy page is not proof of the terms of a future current contract; it is evidence that content licensing and rate display are separate questions. Obtain written confirmation of permitted comparison, attribution, caching, and downstream AI use. [Legacy usage rules](https://legacy.developers.booking.com/api/commercial/index.html?page_url=permitted-use).

Current Net-rate guidance also makes rate distribution conditional on the agreement and approved channels. Some public comparison fields are account-enabled. Do not display every returned rate openly or treat an apparent discount as unrestricted markup. [Net rates](https://developers.booking.com/demand/docs/accommodations/tpi/net-how-to).

### Amadeus

Amadeus Self-Service's FAQ requires a consolidator contract for production ticket issuance. Customer collection is outside the API; payment to the consolidator is a separate arrangement. After ticket issuance, changes, cancellations, and refunds generally require consolidator involvement. The contract must establish disruption monitoring and service coverage. [Official FAQ](https://admin.developers.amadeus.com/self-service/apis-docs/guides/developer-guides/faq/).

A flight reservation identifier is not sufficient evidence of issued tickets. The official flight tutorial distinguishes order creation from the consolidator's issuance step. Model reservation and ticketing separately in the application. [Official flight tutorial](https://github.com/amadeus4dev/developer-guides/blob/master/docs/resources/flights.md).

## Activities

### Viator

Avoid the outdated statement that all affiliate integrations must redirect. Viator's current access-level documentation includes Full + Booking Affiliate access, permitting onsite transactions through its payment solutions, subject to approval and certification. Viator acts as merchant of record for that affiliate arrangement. Basic and Full access generally redirect for payment. [Access levels](https://partnerresources.viator.com/travel-commerce/levels-of-access/).

The technical reference distinguishes Basic, Full, Full + Booking, and Merchant access. It describes availability checks, holds, payment, booking confirmation, cancellation quotes, and booking status. For affiliate booking, payment can use Viator's iframe or API solution. Merchant partners take responsibility for financial transactions and customer support. Choose one commercial mode deliberately; do not mix their obligations. [Technical reference](https://docs.viator.com/partner-api/technical/).

Do not assume Viator's affiliate payment form accepts a saved token from the app's payment provider. A written integration answer or tested supported token flow is required before promising one saved card across activities and the rest of the trip.

### GetYourGuide

The official access article, updated September 2026, lists Basic access at 100,000 monthly web visits or 50,000 app downloads. Reading access lists 1 million monthly visits plus 300 monthly bookings for existing Basic partners. Masterbill booking access is offered by partnership managers and requires a deposit and specialized contract. The app becomes merchant of record in that model. These are published criteria, not forecasts for this business. [Access requirements](https://partner.getyourguide.support/hc/en-us/articles/13981133907613-API-integration-and-requirements).

## Proposed one-account payment design

1. Keep one application identity and traveler profile, with consented provider identifiers behind it.
2. Select a commercial model per category: supplier/partner merchant collects, or this business collects and settles to suppliers. Do not assume a uniform merchant role across the basket.
3. Use hosted payment collection and provider vaults. Store references, never raw card numbers or CVC. A vaulted reference is not a universally accepted supplier payment method.
4. At approval, bind the traveler consent to the item, traveler set, exact quote/version, currency, amount, cancellation terms, and expiry. A later price or material term change needs fresh consent unless a precise user-selected tolerance covers it.
5. Maintain separate payment authorization, capture, supplier commitment, ticket/voucher issuance, settlement, cancellation, and refund states.
6. If a supplier needs CVC or 3DS, pause into an action-required screen, then continue the durable workflow after a verified callback.
7. Treat a multi-item trip as separate commitments. Do not claim all-or-nothing checkout without an actual supplier guarantee. Obtain applicable holds where available, explain partial success, and execute cancellations/refunds only according to their actual terms.

## Proposed price-comparison implementation

Compare the same property, stay dates, occupancy, room configuration, board basis, refund rules, baggage/ancillaries where relevant, payment timing, taxes, fees, and charge currency. Keep unmatched rooms separate. Preserve original supplier amounts; use explicit timestamped FX for informational comparisons only. Explain which channels were searched and when. Use 'lowest comparable price found among connected providers', not 'cheapest everywhere'.

This is an engineering proposal, not a claim of existing coverage or pricing advantages. Contract rights, merchant rates, search costs, booking fees, commissions, reserves, settlement timing, and support costs remain unknown until provider approval and commercial diligence.

## Questions the AI can prepare for provider decisions

- Can this legal entity obtain the required booking tier in the intended customer markets?
- Which exact merchant, settlement, funding, card-vault, refund, and dispute model applies?
- Is cross-provider price comparison permitted, including property content and photographs?
- What rights apply to caching, review summarization, AI processing, attribution, and retention?
- Which post-booking changes and disruptions are available through API, and who owns out-of-hours support?
- Which booking operations offer holds or documented idempotency, and how must uncertain outcomes be reconciled?
- What certification, display requirements, service levels, deposits, reserves, and commercial terms are required?

The AI can prepare integration code, tests, application materials, and concrete commercial questions autonomously. Supplier acceptance, legal entity verification, contractual signatures, funding commitments, and account-holder payment authentication remain external actions.