Skip to content
Travel platforms · design-partner focus

Authorize one booking after the traveler leaves.

A mandate is the traveler-approved boundary for a later action. Attesso checks one proposed booking or rebooking against that boundary while the travel platform keeps its search, booking, checkout, and payment systems.

Available in sandbox
Native passkey mandate
In development
Verified AP2 mandate
Attesso
Canonical authorization runtime
Normalize, evaluate, control single use, and preserve evidence.
Production requirement
Qualified provider
The external rail returns ordered acceptance or invalidation proof.
The platform executes; Attesso returns the decision, lifecycle state, and signed evidence.
Asynchronous workflow

Approval and booking happen at different times.

  1. 1. The traveler approves a bounded mandate with a hosted passkey ceremony.
  2. 2. The agent searches while inventory and price continue to change.
  3. 3. Attesso evaluates the final itinerary against the approved attributes and current lifecycle.
  4. 4. The platform executes through its existing booking and payment rails only after authorization.
  5. 5. A qualified provider proves finality for production execution where that rail supports it.
Concrete mandate example

One flight, bounded attributes.

Traveler
The approved passenger identity
Route
AMS → JFK, no alternate destination
Date
Depart 12–14 September 2026
Cabin
Economy or premium economy
Amount
At most EUR 1,250 total
Expiry
Valid until 18:00 UTC on 31 August
What changes

Inventory moves. Authority does not expand.

Flight number, schedule, inventory, fare, taxes, and total price may change between approval and action. The agent can choose only a result whose typed attributes still fit the approved traveler, route, date, cabin, amount, and expiry limits. Unknown or lossy constraints fail closed.

ALLOW

Every supported constraint matches and Attesso can provision one provider-bound authority chain.

DENY

A route, date, cabin, traveler, amount, expiry, or lifecycle condition does not match.

INDETERMINATE

Attesso cannot establish authority or provider state. The platform must not execute the booking.

Provider-finality boundary

Attesso does not become the booking or payment rail.

The platform remains responsible for execution. A qualified provider must serialize acceptance against irreversible invalidation and return signed, ordered proof. Missing or contradictory proof quarantines the authority; a normal decline or timeout does not release it for another attempt.

Current availability

Available in sandbox: native mandate creation, hosted passkey approval, deterministic evaluation, and signed Attesso evidence.

In validation: provider-interlocked execution and production finality evidence.

Not yet supported: generally available production execution, reusable travel budgets, or a claim that Attesso moves money or issues provider credentials.

Looking for another workflow? Review the validation categories.

Map one travel action with us.

Bring the booking flow, customer constraints, and provider boundary. We will define the smallest credible pilot.