# Reviews, payments and operating obligations

Research checked 8 November 2026; Google Places details and pricing rechecked 9 November 2026. This memo distinguishes documented capabilities from proposed implementation choices. Contract terms and launch jurisdiction remain unresolved; it does not determine the company's legal status.

## Executive recommendation

The seamless experience is technically plausible, but the most ambitious review promise requires negotiated data rights. Build the planning and booking system independently of any one review provider. Begin with content explicitly licensed for the intended recommendation and purchase flow. Treat Google and Tripadvisor integrations as rights-controlled adapters, not unrestricted review databases. A single customer account is feasible; a single saved payment method does not create permission or technical access to transact with every supplier.

## Google reviews and AI

**Documented:** Places API (New) returns at most five reviews per place, ordered by relevance. The overall rating and user-rating count are separate fields. The returned excerpts are not a complete review corpus, so the app cannot claim that its own analysis read all Google reviews. [Place resource reference](https://developers.google.com/maps/documentation/places/web-service/reference/rest/v1/places).

**Documented Google Places costs, checked 9 November 2026:** Requesting `rating` and `userRatingCount` from Place Details triggers the Enterprise SKU, with 1,000 free monthly events and a first paid tier of USD 20 per 1,000 events. Adding `reviews` or `reviewSummary` triggers Enterprise + Atmosphere, with 1,000 free monthly events and a first paid tier of USD 25 per 1,000 events. A request is billed at its highest requested field tier, so field masks matter. Prices are global list rates and usage across projects is aggregated by billing account. [Google pricing table](https://developers.google.com/maps/billing-and-pricing/pricing), [field-to-SKU mapping](https://developers.google.com/maps/documentation/places/web-service/place-details).

**Documented:** Places content has storage restrictions, with place IDs exempt. Content displayed on maps must use a Google map; display without a map requires Google attribution. Photos and reviews require author attribution and source access. The policy also describes review ordering disclosures and requirements for Google's supplied AI summaries. [Places policies](https://developers.google.com/maps/documentation/places/web-service/policies).

**TravelTiger status, 9 November 2026:** Places API (New) is enabled in the Driving time map project and its daily Text Search quota is set to 100. The TravelTiger local preview key allows Maps JavaScript API, Routes API and Places API (New), restricted to the two localhost preview referrers. The local feature flag is enabled. Local browser walkthroughs of hotel and dinner shortlists completed the on-demand lookup flow: exact candidate matches showed Google rating and rating-count cards, while unconfirmed names showed an explicit no-match state. The dinner shortlist showed all ten curated candidates and their map pins; its disclosed order did not change when Google details appeared. The walkthroughs did not retain or record returned Google values. Opening a hotel or meal shortlist makes on-demand Places Text Search calls against curated candidate names. Results stay in page memory and do not affect TravelTiger ranking or preference learning. The interface does not request or display Google review text and does not combine source ratings. Local draft Terms and Privacy pages were added under `policies/`, with missing operator and jurisdiction details marked unresolved. They are not public policies and must be completed and reviewed before public deployment.

**Documented:** Google now provides Maps Experience agent tools. Its service-specific terms allow limited LLM grounding with those tools subject to required source links and other restrictions. Grounded output has specific retention exceptions, and cannot be used to train or improve models. This is a distinct permission from assuming raw Places content may be freely transformed. [Service-specific terms, section 10](https://cloud.google.com/maps-platform/terms/maps-service-terms). The developer guide requires compatible models and controls against model-provider storage or training, alongside source attribution. [Maps Experience agent tools](https://developers.google.com/maps/ai/maps-experience-agent-tools).

**Proposed implementation:** Separate licensed Google display components from the general itinerary model. Preserve source links, freshness and ordering labels. Keep an explicit content-rights manifest. Do not silently put review text into permanent logs, embeddings, fine-tuning sets or another vendor's retained prompts. Confirm terms applicable to the business's billing region before activating an integration.

## Tripadvisor: distinguish legacy Content API from Terra

**Documented legacy position:** The Content API review endpoint describes up to five recent reviews, with plan-dependent differences. It also points developers toward the newer Terra platform. [Legacy Location Reviews](https://tripadvisor-content-api.readme.io/reference/getlocationreviews). Legacy master terms grant only a narrow internal non-commercial AI testing exception; other AI use requires a separate signed agreement. They also constrain mixing and display. [Legacy API terms](https://tripadvisor-content-api.readme.io/reference/api-master-terms-new). Legacy caching allows location IDs, not general content retention. [Legacy caching policy](https://tripadvisor-content-api.readme.io/reference/caching-policy).

**Documented current platform:** Terra offers locations, reviews, photos, geographic information and Agentic Search. Content access and usage rights vary by package. An API key is not blanket access to every endpoint. [Terra overview](https://docs.terra.tripadvisor.com/docs/overview), [Terra access rules](https://docs.terra.tripadvisor.com/docs/rate-limits).

**Material contract findings:** The newer Master Partnerships Terms allow consumer chatbot summaries through the Agentic API when that service is in the applicable Order. They prohibit combining licensed content into a new aggregate rating/review system and prohibit displaying content or summaries alongside third-party booking or inventory functions. Attribution, AI disclosure and faithful presentation are required. The Order takes precedence over the master terms. These provisions make the desired cross-source hotel recommendation and booking card a negotiation issue. [Master Partnerships Terms, sections 1.2, 3.1.2, 3.4.2 and 3.4.5](https://developer-tripadvisor.com/partner/master-partnerships-terms-and-conditions/).

Terra's caching policy restricts retention except where the contract provides otherwise, with a location-ID exception. Do not assume that generic performance guidance about caching grants storage rights. [Terra caching policy](https://docs.terra.tripadvisor.com/docs/caching-policy).

**Proposed commercial request:** Obtain express permission for consumer AI recommendations, source-separated ratings, ranking inputs, co-display with other review sources, adjacent third-party booking functions, retention and model-provider processing. Send actual proposed screens for approval. If rights are unavailable, omit Tripadvisor content from that purchase experience rather than promise a feature the standard contract does not support. Do not build a blended Google/Tripadvisor star rating by default.

## One account and a saved card

**Documented:** Stripe supports saving a payment method through SetupIntents and charging it later. The customer must consent to the defined future use, and the business must retain evidence of that agreement. An off-session payment can still require authentication and a customer return flow. [Save and reuse payment methods](https://docs.stripe.com/payments/save-and-reuse?payment-ui=elements).

Stripe describes payment-method sharing across its connected accounts, with account and country requirements. This is a bounded Connect capability, not universal transfer of a Stripe token to independent airlines, hotels or agencies. [Share methods across connected accounts](https://docs.stripe.com/connect/direct-charges-multiple-accounts).

Stripe's hosted collection options can keep raw card data off the app's servers and reduce PCI scope. PCI compliance remains shared responsibility. [Integration security guide](https://docs.stripe.com/security/guide). PCI rules prohibit retaining card verification codes for future purchases, even with customer permission. [PCI SSC FAQ 1574](https://www.pcisecuritystandards.org/faqs/1574/).

**Proposed architecture:** Keep app account identity separate from supplier identities. Save processor references and permitted masked details, never card security codes. Choose a documented settlement model for each supplier: platform charge and supplier settlement, supplier-supported vaulted payment, approved connected account, or another contracted payment arrangement. Keep raw card data away from AI tools, logs and support exports. Do not model saved cards as reusable credentials for browser automation.

**Proposed consent design:** Explain precisely whether “Approve” saves a selection or initiates a purchase. The booking authorization must bind itinerary version, traveler identities, supplier offer IDs, currency, maximum amount, terms, expiry and the handling of partial success. A changed fare, hotel room, dates or cancellation policy invalidates the affected approval. Saving a card is not open-ended permission to purchase future trips.

## Travel obligations by market

**US:** California's seller-of-travel rules cover businesses arranging or advertising covered travel, with registration and financial requirements and specified exemptions. This is evidence that incorporation location alone does not settle launch eligibility. A lawyer should map all intended customer states and operating roles. [California registrant FAQ](https://oag.ca.gov/travel/reg-faqs). The US DOT explains that ticket agents acting as merchants of record have airfare refund responsibilities for cancellations or significant changes. The payment architecture therefore affects operating liability. [DOT refunds guidance](https://www.transportation.gov/individuals/aviation-consumer-protection/refunds).

**UK:** The CAA states that ATOL requirements can apply to businesses outside the UK advertising and selling covered flight arrangements to UK consumers, regardless of flight departure point. Qualifying exemptions and agency structures require specific assessment. [CAA: Do I need an ATOL?](https://www.caa.co.uk/atol-protection/atol-requirements-for-the-travel-industry/do-i-need-an-atol/). Government package-travel guidance was updated on 28 October 2026 to address amendments. Check the actual commencement provisions applicable to the launch date, not an old cached summary. [Current UK guidance](https://www.gov.uk/government/publications/package-holidays-complying-with-regulations-guidance-for-businesses).

**EU:** A single website selling different travel services can constitute package travel even under separate supplier contracts. Organisers can be responsible for performance and pre-contract information. [Your Europe business guidance](https://europa.eu/youreurope/business/selling-in-eu/selling-goods-services/package-travel/indexamp_en.htm). The 2026 amending directive sets national transposition by 29 September 2028 and application from 29 March 2029. Do not present its future changes as already applicable national requirements in November 2026. [Directive (EU) 2026/1024, Article 3](https://eur-lex.europa.eu/eli/dir/2026/1024/oj/eng).

**Proposed launch choice:** Start in one expressly approved customer market with one defined operating model and a specialist travel partner where appropriate. Confirm which entity is the organiser, seller, agent and merchant of record; who handles refunds, disruptions and insolvency protection; and what insurance, reserves and registrations are necessary. Splitting approvals into separate buttons must not be treated as a legal workaround.

## Autonomous engineering contract

The AI can prepare architecture, provider adapters, consent screens, tests, documentation and onboarding materials autonomously. It should report facts and contract status, not invent production entitlement. The owner or authorised specialists must establish the business entity, sign commercial contracts, complete identity checks, determine the legal operating model, fund any reserves and approve commercial commitments. Genuine payment authentication still belongs to the traveler when required.

Recommended implementation rules:

1. Maintain a provider registry recording allowed uses, retention, attribution, AI permission, booking capability, applicable contract and approval status.
2. Enforce money and booking decisions in deterministic application code. The language model proposes structured plans and explanations.
3. Reprice before purchase. Revalidate schedule feasibility, total cost and approvals. Pause for changed material terms.
4. Use an idempotent, durable workflow with independent payment and supplier states. Unknown supplier outcome is a reconciliation state, not a reason to buy again.
5. Test payment authentication, duplicate requests, timeouts, partial booking, cancellation, refund reconciliation and stale offers before taking real money.
6. Provide a human service path for disruptions and unresolved supplier outcomes. A launch promising automatic purchases also needs accountable post-purchase service.
7. Keep public copy scoped to verified capability: “best fit among available connected offers,” with source coverage and freshness, rather than “best price everywhere.”

These are proposed engineering controls. Supplier contracts and regulator-specific review must determine their final implementation.


## TravelTiger Google Places Text Search pilot

The approved fields are candidate display name, `rating`, `userRatingCount`, `priceLevel` and `googleMapsURI`, requested through the Maps JavaScript Places `Place.searchByText` method. No review text, photos, Google coordinates or address are requested. Requesting rating, count and price level makes each query a Text Search Enterprise event: Google's published global list price is 1,000 free monthly events, then USD 35 per 1,000 in the first paid tier. The project daily cap is set to 100 Text Search requests, which would cost up to USD 3.50 per day after the shared monthly free cap at that list price. Actual cost depends on aggregate billing-account usage and applicable pricing. [Pricing, checked 9 November 2026](https://developers.google.com/maps/billing-and-pricing/pricing).

The implementation is designed to request ten candidates at most when a hotel or restaurant shortlist opens. It requires an exact normalized candidate name match and a returned Google Maps URI before showing the fields. Unconfirmed results remain unavailable. Google fields stay in page memory and are excluded from app storage, exports, logs, map markers, TravelTiger ranking and preference learning. Attribution is shown in a distinct Google Maps card. Retry is user initiated to avoid automatic billable calls. Google requires publicly accessible Terms of Use and Privacy Policy pages. Local drafts exist, but they are not public and lack the operator and jurisdiction details needed for release, so the app must remain preview-only. [Text Search (New)](https://developers.google.com/maps/documentation/javascript/place-search), [Places attribution and data policies](https://developers.google.com/maps/documentation/places/web-service/policies).