Agent-Ready Payments: How Bookings Get Paid When Nobody Fills a Form

Friday, 9:42 PM. A traveler asks their AI assistant: "Book me a 60-minute deep-tissue massage near my hotel tomorrow afternoon, under €80, with a 24-hour cancellation window."

The agent finds three providers. Two need a card-on-file flow that opens in a browser. The agent can't open a browser. It picks the third — the one that accepted the booking and held the deposit in a single API call, against a mandate the user pre-authorized last week.

You weren't on that shortlist. Not because your prices were wrong. Because the agent couldn't pay you.

Discovery is solved by AEO. Connection is solved by MCP. Payment is the next failure mode — and most booking systems aren't ready for it.

Why Classic Checkout Breaks for Agents

A normal checkout assumes four things, all of which break the moment the buyer is an AI agent:

1. A visible 3DS challenge. Strong Customer Authentication (SCA) under PSD2 was designed to interrupt a user with a UI flow. Agents don't see UIs. If your only path through SCA is a redirect to a card-issuer page, the booking fails silently.
2. A browser session that stays open. Tokenized card vaults often hand back an iframe or a redirect target. Agents call APIs and move on; they don't keep tabs alive.
3. A human thumb on a "Confirm" button. Two decades of UX research have been optimizing the moment a human commits. That moment doesn't exist anymore.
4. Form fields for card data. Even if the agent has a payment method, it's almost never raw PAN. It's a token, mandate, or a delegated wallet handle.

If your checkout assumes any of these, the agent moves on to a provider whose checkout doesn't.

Three Authorization Models in Agentic Commerce

There isn't one right pattern. Today, three models are converging — each with a different trust and latency profile:

1. Pre-authorized mandates

The user grants the agent (or the wallet behind the agent) standing authority to charge specific service categories up to a cap. The agent books and charges in a single API call.

• Best for: trusted platforms, recurring or low-value bookings, frequent travelers.
• Mechanics: Stripe Customer mandate, ACH/SEPA mandates, card-on-file with off-session intents.
• Trade-off: highest convenience, lowest friction. The user can't review every charge individually.

2. Delegated payments

The agent prepares a payment intent and hands it to a verified user device for tap confirmation. The booking is held; the human ratifies.

• Best for: higher-value bookings, first-time providers, regulated industries.
• Mechanics: PaymentIntent created off-session, push to the wallet, capture after biometric confirmation.
• Trade-off: strong fraud posture, but adds 5–60 seconds of human-in-the-loop latency.

3. Per-transaction confirmations

The agent commits the booking with a hold; the user receives a notification, taps to confirm, capture happens. If they ignore it, the hold expires and the slot reopens.

• Best for: providers without an existing mandate relationship to the user.
• Mechanics: PaymentIntent with capture_method=manual, 7-day auth window, webhook on capture.
• Trade-off: highest drop-off, lowest trust requirement.

Most providers will end up supporting models 2 and 3. The wallet — Apple Pay, Google Pay, or an agent-native wallet — decides which one fires for a given transaction.

Holds and Deposits as the Trust Layer

The cleanest pattern we see: the agent commits early, the human ratifies later, the slot is held in between.

Concretely:

1. Agent calls createBooking with a paymentIntent whose capture_method is manual.
2. The card is authorized — funds reserved, not captured. On most card networks, that auth holds for up to 7 days.
3. Your system emits a webhook and a push to the user.
4. User confirms → you capture. User ignores → the auth expires; the slot reopens automatically.

This is graceful degradation. The agent acts decisively, the user retains the final say, and you never end up with a phantom booking blocking real customers.

Refunds and No-Shows When the Booker Isn't Human

When the buyer is an AI, the dispute landscape shifts:

• The agent's log becomes evidence. A timestamped tool-call trace ("user requested booking, agent confirmed, payment captured at T+3.2s") is stronger evidence than a session cookie ever was.
• Chargeback risk drops for transactions where a verified user mandate signed off — the issuer treats it closer to a recurring authorized charge than a card-not-present dispute.
• Pre-paid deposits get more important. They de-risk the no-show case where the agent booked enthusiastically but the user never showed up.
• Your no-show policy must be machine-readable. If your cancellation terms are buried in a legal page, the agent ignores them — and your refund decisions look arbitrary later.

Expose policy as structured data: cancellation window, deposit amount, refund tiers. Agents read these before they book, not when something goes wrong.

What Timerise Ships Today

If you're building on Timerise, the pieces are already there:

• paymentIntent with manual capture on every booking mutation. Default hold window: 7 days, returned in the response so the agent knows when it expires.
• Stripe customer mandates that bind to a Timerise booking session — re-usable across providers under the same merchant of record.
• Webhook acknowledgement as the canonical "booking confirmed" event. Don't trust the HTTP 200 from your booking call; trust the webhook.
• Idempotency keys required on createBooking and capturePayment. Replay-safe by construction.
• Structured error codes that an agent can route on without parsing English: card_declined, insufficient_authorization, slot_taken, mandate_revoked, sca_required.

These map cleanly to the MCP tools we ship, so an agent connected over MCP can recover from a failed payment without escalating to the user — most of the time.

The Agent-Ready Payments Checklist

If you want bookings from AI agents, audit your payment surface against this list:

1. Idempotency keys on booking and payment mutations. The agent will retry; make retries safe.
2. Webhooks that double as booking confirmation, not optional listeners.
3. Structured error codes — strings the agent can switch on, not human messages.
4. SCA exemption flags in your responses (Low Value, Trusted Beneficiary, MIT) so the agent knows when a challenge is avoidable.
5. Manual-capture support with the hold window (in seconds) returned in the response.
6. Refund and cancellation policy as fields, not free-form text. Cancellation cutoff in ISO 8601, refund percentage as a number.
7. Receipt URL in the success response. Agents drop these into the user's wallet automatically.

Half of these are normal API hygiene. The other half is what separates "we accept payments" from "agents will use us."

The Payment Is the Real Handshake

Discovery (AEO) gets you on the shortlist. Connection (MCP) lets the agent talk. Payment is where the booking actually becomes a booking.

If your checkout still assumes a browser and a human thumb, you've built an inviting front door with a lock the agent can't pick. The agent will move on to the next provider on its list — silently, with no ticket logged for you to debug.

The next twelve months will sort booking businesses into two camps: those whose money moves at agent speed, and those still waiting for a confirmation click that never comes.