The product

Three records of the same booking. Relay notices when they stop agreeing — and fixes it.

A travel order lives in three places at once: the agreement your customer accepted, the charge your processor captured, and the reservation the supplier actually issued. Nothing in the stack compares them. Relay does — on every order, continuously, and it says something the moment they diverge.

Why this breaks, and why nobody catches it

Booking a flight is not one transaction. It is a payment authorisation, a fare quote that expires, a supplier request that can partially succeed, a ticketing step that happens seconds or minutes later, and a confirmation that may never arrive. Each step has its own system of record and its own idea of what went right.

When an AI agent books on a traveller's behalf, the gap widens. The agent commits to something in natural language, the processor captures a number, and the GDS returns a status code. No human ever sits between them and asks whether the three describe the same trip.

The failures are not exotic. They are mundane, frequent, and expensive: money taken for a ticket that never issued, a duplicate capture from a retried request, a fare that drifted between quote and charge, a refund that was initiated and then quietly never landed.

AgreedSFO → NRT · $2,480 · refundable
Charged$2,480 · captured ×2
Confirmedstatus: failed

Two flags on one order: duplicate_charge and unissued_after_charge. Severity: critical. Recommended resolution: void the second capture, refund in full, re-attempt issuance. This is the output, not a dashboard you have to read.


How it works

One call per order. Ten checks. A verdict you can act on.

01 — Submit

Send the three views

POST the order to /v1/reconcile with whatever you have: what was agreed, what was charged, what the supplier confirmed. Missing fields are never treated as mismatches — Relay only judges what you actually gave it.

02 — Reconcile

Ten deterministic rules

No model, no probability score. Amounts, currencies, routes, dates, passenger names, capture counts and fare rules are compared directly. A flag is a fact you can show a customer, not a guess.

03 — Watch

Time is a failure mode

The worst outcomes are silences: nothing ever confirms. Relay holds an order open with a deadline — 20 minutes for ticketing, 5 days for a refund — and flags it when the deadline passes with no news.

What it detects

Every flag carries a severity and a recommended resolution.

unissued_after_chargeMoney taken, supplier order failed
duplicate_chargeMore than one capture for one order
partial_orderOnly part of the itinerary confirmed
price_driftCharged amount ≠ agreed amount
currency_mismatchCharged in a different currency than quoted
refund_not_landedRefund initiated over 5 days ago, never settled
date_mismatchConfirmed departure date ≠ agreed
route_mismatchConfirmed route ≠ agreed
passenger_mismatchConfirmed passenger name ≠ agreed
fare_rule_driftSold refundable, confirmed non-refundable

And what it fixes

Five of the ten it can resolve for you.

Relay works out the fix and the amount from the order itself, then waits for your approval.

unissued_after_chargeRefund the charge in full
duplicate_chargeRefund only the surplus captures
price_driftRefund the difference
partial_orderCancel the supplier order
passenger_mismatchRequest a name correction
Approve first

Nothing moves on its own

Remediation is off until you enable it, and a plan cannot execute until it is approved. Both are enforced by Postgres constraints, not by application code. You can raise a per-flag ceiling to let small, well-understood fixes run automatically.

Exactly once

No double refunds

Each plan carries a key derived from the order, the flag and the action — reused all the way through to Stripe. Proposing twice returns the same plan; a retry after a timeout returns the original refund rather than making a second one.

Auditable

Who decided what

Every transition is written to an append-only log that nobody can edit or delete — who approved, when it ran, what the provider returned. If money moved, the record says why.


Who it's for

AI travel agents

You book on a user's behalf and you carry the blame when it goes wrong. Relay is the check that runs before your user finds out.

OTAs and TMCs

Your ops team already reconciles by hand at month end, from spreadsheets. This is that job, done per-order and in real time.

Fintechs in travel

You move the money and see only your side of it. Relay matches your settlements against what the supplier actually delivered.

What Relay is not

It does not book anything. Relay never touches your supplier connections or your inventory. It reads three records and compares them.

It does not move money without your approval. Relay proposes the exact fix and the exact amount; nothing executes until a person says yes. Remediation is off entirely until you switch it on, and that rule is a database constraint rather than a setting in the code — a redeployed function with a bug in it still cannot refund something nobody approved.

It does not decide what a broken trip is worth. Five of the ten flags have no automatic action, because the safe move depends on whether the traveller still wants the trip. Relay escalates those to a person instead of guessing, and reports coverage as resolved outcomes rather than proposed plans so the gap stays visible.

It does not guess. Every flag is a deterministic comparison you can reproduce by hand. False positives are the fastest way to lose trust in a monitoring tool, so about half our test suite asserts that Relay stays quiet.