Agent-Safe Payments: Letting AI Agents Book Without Losing Control

In May, Skift reported that Expedia Group is preparing to launch a business-to-business Model Context Protocol (MCP) server so that partners’ AI agents can connect directly to its inventory. The same report put its B2B business at 21 billion API calls a day.

When the largest intermediaries start cutting doors for agents, the question for an independent supplier changes. It is no longer whether AI agents will try to book you. It is what happens in the minute or two when one of them tries to pay.

Search is reversible. Quotes are reversible. Payment is the moment an agent’s action becomes real money, a real seat in a real van, and a real cancellation policy that someone will be held to. That is where the controls belong.

Five questions every agent payment must answer

Before money moves, the supplier’s system should be able to answer:

1. Who authorized this, and within what limits? The traveler is the customer, not the agent. The agent needs scoped authority.
2. What exactly was agreed? Price, taxes, fees, dates, names, cancellation terms.
3. Is this the same request I saw a second ago? Agents retry and networks drop. Duplicates are the default failure.
4. Does a person need to see this first? Some transactions are too large, too final or too unusual to complete without the traveler confirming directly.
5. What is the evidence if it’s disputed later? A conversation transcript that the agent controls is not evidence you can rely on.

Each answer maps to a building block.

The building blocks

The mandate

A mandate is a scoped, expiring authorization from the traveler to the agent: a maximum amount and currency, the merchant, allowed product types, a date range, whether non-refundable charges are permitted, and an expiry. The agent presents it; your system verifies it with the payment provider or wallet that issued it. A free-text field saying “the user approved this” is not a mandate.

The quote lock

A quote binds price, taxes, fees, inventory and cancellation terms into one object with an ID, a fingerprint of its contents and an expiry. Fifteen minutes is a reasonable default for tours. Payment must reference the quote ID, and if anything changes, the agent requests a new quote. That protects the traveler from bait-and-switch, and protects you from an agent paying a stale price.

The hold

Booking is two-phase: hold, then confirm. A hold reserves inventory for the life of the quote. Because agents can open holds at machine speed, cap them — for example, no more than three concurrent holds per agent per departure — or a single misbehaving agent can make a popular date look sold out.

Idempotency

Every write call — hold, pay, confirm, cancel — carries an idempotency key. If the same key arrives twice, the second call returns the first call’s result instead of doing the work again. This single control prevents most double charges and double bookings.

Tokenized payment

The agent never sees a card number. It presents a payment token issued by the traveler’s provider and bound to the mandate. That keeps card data out of the agent’s context window, out of your logs and out of your compliance scope.

Step-up confirmation

Some transactions pause until the traveler confirms on their own device: anything over a threshold, anything non-refundable, the first booking from an agent you haven’t seen before, mismatched traveler names, or terms outside the mandate. The traveler sees a plain summary — dates, names, total, what is refundable and until when — and taps to approve. The agent waits.

One booking, minute by minute

A traveler asks her assistant to book a three-day guided canyon trip for two in late September, “under $1,600.” The supplier exposes its catalog through an agent-facing MCP server. Here is what happens:

Time	Step	Detail
10:02:14	Search	Agent queries the catalog; three departures fit
10:02:40	Quote	Sept 24 departure, two guests: $1,480 including taxes and fees. Deposit of 30% ($444) is non-refundable; the $1,036 balance is due Aug 25 and refundable until then. Quote valid for 15 minutes
10:02:41	Hold	Two seats held until 10:17:40
10:03:05	Mandate	Agent presents a mandate: up to $1,600, this merchant, guided tours, expires tonight, non-refundable charges allowed
10:03:06	Step-up	A non-refundable deposit plus a first booking from this agent triggers a confirmation on the traveler’s phone
10:04:30	Approval	She reviews the summary and approves
10:04:31	Payment	Agent submits a token for $444 with the quote ID and an idempotency key
10:04:39	Retry	After a network timeout, the agent retries with the same key and receives the original result: one charge
10:04:40	Confirm	Booking confirmed; confirmation, policy and balance schedule sent directly to the traveler; booking tagged with the agent’s identity

Two details deserve attention. First, the balance. The mandate expires tonight; it is not standing authority to charge $1,036 in August. The balance goes to the traveler as a direct payment link, or runs under a separate stored-payment agreement she makes with you. Second, the confirmation goes to the traveler directly. If the agent’s summary to her is wrong, your own message is the correction.

Risks and the controls that answer them

Risk	Control
Agent overspends or books the wrong product	Mandate scope checked on your side; quote lock
Price or terms change between quote and payment	Quote fingerprint and expiry
Double charges from retries	Idempotency keys on every write
Inventory squatting	Hold expiry and per-agent hold limits
Card data exposure	Tokens only; no card numbers through the agent channel
“I never agreed to that”	Step-up record, fingerprinted quote and audit log
Prompt injection steering the agent toward an odd booking	Mandate must match; unusual requests always step up
Messy refunds	Machine-readable policies; refunds to the original method; cancellations through the same guarded interface
Unknown or misbehaving agents	Agent identity on every call, rate limits, per-agent revocation

None of these depend on trusting the agent’s reasoning. They are enforced by your system, at your boundary. That is the design principle behind Nova’s Agent Gateway: agents can be as clever as they like, but the checkout has to be strict.

What the audit record should hold

When a booking is disputed six weeks later, the question is whether someone outside engineering can reconstruct what happened in five minutes. For every agent transaction, keep:

• The quote — its ID, fingerprint, full terms and expiry.
• The mandate — its ID, limits and issuer, as verified at the time.
• The agent — its registered identity, the autonomy level it held, and the client version if available.
• The step-up — when it was sent, through which channel, the exact summary shown and the moment of approval.
• The payment — the token reference and the provider’s response, never the card details.
• The idempotency key, and every retry that arrived with it.
• Every state change — held, paid, confirmed, modified, cancelled — with timestamps.
• Every message sent to the traveler, as sent.

Store it append-only, and make it readable as a plain timeline. A record nobody can interpret under pressure is not much better than no record.

An autonomy ladder

You don’t have to grant every agent full booking power on day one. Treat permissions as levels, granted per agent and earned through behavior:

• Level 0, read. Catalog, availability and policies.
• Level 1, quote and hold. Reserve inventory briefly; the traveler completes payment through a link.
• Level 2, book refundable products within a mandate cap.
• Level 3, book anything within the mandate, with step-up for non-refundable or over-threshold charges.
• Level 4, modify and cancel existing bookings.

Promotion criteria can be simple. For instance, an agent moves from Level 1 to Level 2 after 200 holds with a hold-to-booking conversion above 15% and no disputes. Demotion should be automatic: a spike in disputes, abandoned holds or cancellations drops an agent a level until someone takes a look.

What stays with people

Agents can assemble the trip and carry it to the edge of payment. For irreversible money, the traveler decides. For exceptions — groups above your standard size, medical or mobility needs, private charters — your staff decides, and the booking should land in the same exception queue your team already works from in booking operations. “Draft, don’t decide” applies to agents, too.

Security practices matter here as much as product design: least-privilege access for every agent credential, encryption in transit and at rest, and logs that redact anything sensitive. Our security and trust notes describe how we approach that side.

Before you let an agent pay

1. Publish machine-readable deposit and cancellation policies for every product.
2. Issue quotes with IDs, content fingerprints and expiries.
3. Implement holds with expiry and per-agent limits.
4. Require idempotency keys on all write calls.
5. Accept tokenized payments only.
6. Write down your step-up rules: amount, refundability, new agents, name mismatches.
7. Send confirmations directly to the traveler.
8. Record agent identity on every booking, for attribution and revocation.
9. Keep an audit log that a dispute team could read without an engineer.
10. Build a per-agent off switch, and test it before you need it.

For a fuller pre-launch list, the agent-ready checklist covers catalog and policy work as well as payments, and agentic commerce readiness is the engagement that takes a supplier from Level 0 to a supervised Level 3. The order you work in matters less than the principle: decide the rules for money before an agent asks.