What is agentic commerce? What a hotel should know when an AI assistant pays

Agentic commerce is the trade term for purchases an AI assistant carries out on a person's behalf, including the payment. For a hotel it changes three things: who authorized the purchase, what proof arrives with the booking, and who answers when the guest disputes it. No hotel booking in Türkiye was found running this way.

A confirmation arrives with a booking reference, a guest name, and a card number that belongs to nobody in the room. Nothing on the reservation says who authorized the payment, what limit applied, or what to do when the guest says the price was wrong. After reading this article you will be able to say what agentic commerce is, what proof of authorization looks like, where an agent payment sits among the payment models you already run, and what to fix in your terms before the first such booking arrives.

What is agentic commerce, in plain words?#

Agentic commerce is buying and selling where an AI assistant acts for a person: it finds the item, applies the person's conditions, and completes the payment. The new part is not the assistant; it is the money moving without a person clicking buy.

Keep the definition narrow. An assistant acting within limits a person set, up to and including payment, is agentic commerce. Ordinary online booking is a person deciding and clicking; agentic commerce is a person delegating and checking afterwards. The distinction matters at the front desk, because the two arrive as the same reservation but carry different evidence.

Three dated events explain why hotels hear the term now, and none of them is a forecast. In October 2025 a major AI company announced a plan for third-party apps inside its assistant, with two large booking sites first, built on an open connection standard (Skift, 6 October 2025). In March 2026 a report said that company was scaling back direct in-chat checkout, which it did not comment on (Reuters via The Star, 6 March 2026). In August 2026 a search company began rolling out hotel booking in its AI mode for US travelers only, with the traveler choosing and paying, and no booking made by the assistant on its own (Skift, 27 August 2026). If you want the full picture of announcements, read what has actually been announced about AI assistants booking hotels.

The term itself is trade shorthand, not a standard and not a product. Two proposals can use it and mean different things.

Separate the two halves a hotel tends to merge. Discovery and booking is an assistant finding and holding a room. Settlement is an assistant paying. The second is what agentic commerce adds, and it is the half that touches the front desk and the finance office.

One stay, three parties: the traveler, the assistant and the hotel#

Three parties now stand where two used to: the traveler who set the conditions, the assistant that acted on them, and the hotel that must deliver the room and issue the documents. The hotel's duties do not shrink because a piece of software made the booking.

Name the roles precisely. The traveler is the person whose money and intent are involved. The assistant is software acting for that person. The hotel is the merchant that provides the stay and issues the fiscal document.

The identity gap is what the front desk meets first. The name on the reservation, the name on the card and the person at the desk can be three different things, and none of that is fraud by itself. People have booked rooms for family members for decades; an assistant widens the pattern, it does not invent it.

The legal frame does not change. In Türkiye, every stay involves a payment, a fiscal document (an invoice or e-document), a guest identity notification (KBS) and personal data (KVKK). An assistant changes who initiates, not what the stay requires. When an assistant books, what reaches the front desk is an ordinary reservation with an unusual name pattern and no extra paperwork; what reaches the front desk when an AI assistant books your hotel covers that arrival path in detail.

One staff question follows immediately: what a receptionist may confirm to an assistant that is not the guest. That has its own answer in what staff may share and confirm when a guest's AI assistant contacts the hotel, and this article does not answer it.

What you can write down now, before the case appears: which channel the booking came through, who the payer is, and which address the confirmation went to. That is the raw material of every dispute file later.

Who gave permission, and what proves it?#

A signed instruction from the person, held by the assistant and shown to the seller, is the proof. AP2 calls these mandates: digital contracts, signed cryptographically, that record what the person asked for and the limits they set.

AP2's own framing of the problem is worth quoting in substance. Google says today's payment systems generally assume a human is directly clicking buy, and the protocol addresses three questions: authorization, authenticity and accountability.

Present and delegated: two different permissions#

AP2 works through two mandate types. When the person is present, an intent mandate records the request, and the person's approval signs a cart mandate that fixes the exact items and price. When nobody is present, the person signs a detailed intent mandate in advance, setting price limits, timing and other conditions, and the assistant may then produce the cart mandate once those conditions are met.

The announcement describes the mandates as tamper-proof, cryptographically signed digital contracts. Do not carry that phrase over to any hotel record: a hotel's own log is at best tamper-evident, meaning changes can be detected, not prevented.

Be honest about the gap. A hotel that receives an ordinary reservation today sees none of this. The mandate lives between the person, the assistant and the payment side, and the hotel may only ever see a reference.

What the hotel can realistically ask for#

When a booking looks assistant-originated, request the authorization reference and the limit that applied, and store both with the reservation. Ask at booking time, because they will not appear later.

Note the size of the announcement without turning it into a market claim. Google said it was working with more than 60 organizations on the protocol, named in the announcement (Google Cloud Blog, 16 September 2025 (opens in a new tab)). A working group is not adoption.

Which payment model does the hotel already know?#

All three models a hotel already runs: the guest pays at the desk, the site collects and settles later, or a virtual card is issued per booking. An agent payment is a fourth front end on the same settlement, not a new way of accounting for the money.

Walk through the existing models. With pay at the hotel, the guest holds the money until checkout, the reservation shows a guarantee, and the risk sits in no-shows. With the site collecting, the site holds the money first and settles later, and the risk sits in the settlement terms and timing. With a virtual card, a single-use card number is issued for one booking and charged for the amount the booking allows, which is why the amount and the dates on the reservation matter more than the card itself.

An agent payment sits alongside these. The assistant pays with a credential backed by the person's mandate, and the hotel still receives a settlement through a card or a wallet, not a new currency.

The mismatch that causes most trouble: the amount charged, the amount on the reservation and the cancellation terms can drift apart when a third party assembles the booking. Whatever the payment route, the stay still produces a fiscal document and a guest identity notification. In our own system, e-invoices wait for a person's review before sending. For the detailed comparison, read hotel collect, OTA collect and virtual cards compared.

When the guest disputes it: chargebacks and the booking record#

The dispute arrives weeks after checkout, as a card chargeback, and it is answered with documents the hotel kept, not with the protocol that authorized the payment. The hotel that can produce a signed registration, the terms accepted at booking and the correspondence usually has the stronger file.

The sequence is plain. The traveler disputes the charge with the card issuer, the issuer asks the hotel's bank for evidence, and the hotel is asked for a file within a deadline it does not set.

What belongs in that file: the reservation record, the signed registration card, the cancellation or no-show terms as presented at the time of booking, the confirmation sent and to whom, and any messages exchanged. The new evidence a hotel may not have is the mandate reference and the limit that applied. Ask for them at booking time, because they will not appear later.

Separate the two disputes that get confused. The traveler saying the charge is unauthorized needs evidence of authorization. The traveler saying the amount or the terms were wrong needs the terms as shown at booking. They need different evidence, and mixing them weakens the file.

This article does not rule on liability. Who answers when an assistant gets it wrong is a question for the hotel's own legal and payments advisers, and the answer depends on the terms, the mandate and the card scheme's rules. One rule you can apply today: if the hotel cannot reconstruct who authorized the booking and on what terms, it cannot answer a chargeback well, whatever the payment route. Answering a card chargeback with the right evidence covers the file in detail.

What should a hotel check in its own terms and booking path today?#

Check whether your terms bind whoever made the booking rather than only the guest who stays, and whether your booking path captures who the payer is. Both are cheap to fix now and expensive to fix after a dispute.

Terms first. Cancellation, no-show and modification clauses should be written to bind the person who booked and paid, not only the person who arrives. Identity next: a field or a note that records the payer when the payer is not the guest, and a rule for who may cancel or modify the booking. Refunds need a written route that sends money back to the payer, whoever that turns out to be.

Confirmations matter as records. Capture the address the confirmation goes to, and keep a copy with the reservation rather than only in an inbox. Keep a retention habit for the authorization reference, the terms as shown at booking, and the messages exchanged. Finally, name one person who handles an assistant-originated request and knows what may be confirmed and what may not.

The fuller version is in the AI booking readiness checklist for hotels.

Where AI Otel stands on agentic booking#

Booking by AI assistants is built and runs in a demo: an AI assistant can find, hold and book a room on our demo property within limits the hotel sets. The demo property is fictional, and it does not demonstrate payment.

Say what the demo does not show, because the boundary is the point. No payment is carried out in the demo, no card is charged, and no mandate is issued or checked. And the honest zero: we have no trained model yet, and the product says so on screen. For context, OtelCiro works with paying hotel clients today; the hotel operating system is built and working, ahead of launch. You can read more about the AI Otel platform.

What to do next#

Take your own cancellation, no-show and refund terms and read them as if a software assistant had accepted them on someone's behalf. If they do not name the booker and the payer, rewrite them this month, then work through the readiness checklist before the first such booking arrives. If you want to discuss how your hotel prepares for assistant-originated bookings, request a briefing.