The Universal Commerce Protocol (UCP) project has released its first lodging booking draft, with Google, Booking.com, Expedia and major hotel groups helping shape a common specification for AI-assisted reservations.
The September 25 announcement says the draft has been merged into the project’s repository and opened for public feedback. It credits a Lodging Tech Council including Amadeus, Booking.com, Expedia, Google, Hilton, Marriott and Trip.com.
The documentation remains a work in progress, with potentially breaking changes ahead.
What happens after an assistant finds a room
The booking capability takes property and rate identifiers from an earlier search process. The business then checks inventory, calculates binding prices and attaches cancellation terms. A confirmed reservation is created when the booking session is completed.
That adds technical detail to the plans SEW previously covered for hotel bookings within Google Search. This release opens the shared specification to scrutiny; the announcement provides no consumer rollout date.
The business remains the merchant of record. Unless the AP2 Mandates extension is supported, the user must finalize the booking manually through a trusted interface.
The full price and the payment schedule
The lodging draft requires the full stay liability to be presented before confirmation, including mandatory charges collected at the property. Stay totals cover the entire duration rather than a single night.
The separate Payment Terms extension represents what is owed and when through payment schedules. Its documentation gives lodging as an example: a business can offer full payment at booking or a first-night payment followed by the balance at check-in.
Each schedule needs a buyer-facing description of when and how payment is due. If selecting a term changes the total, the returned checkout must reflect the change and the platform must display the updated response.
For a traveler comparing rates, the amount collected today can therefore be shown alongside the complete financial commitment.
Developers are asking about failed requests and changed terms
In the announcement’s replies, contributor KukretiShubham asks how implementations should avoid two reservations when an API completion request times out and the customer finishes the same session through a website.
The contributor also asks how earlier approval should be invalidated if a refundable room becomes non-refundable, or payment switches from later to immediate, while the total stays unchanged.
These are requests for clarification and worked examples in the public discussion. The thread supplies no demonstration of a duplicate reservation occurring.
The AP2 Mandates documentation describes signed proof that a user authorized a specific checkout state and funds transfer. That binds authorization to the terms being approved. The contributor is asking for a lodging-specific example of how a changed policy should trigger renewed approval.
Our take
The same room at the same price can represent a different purchase when its cancellation terms or payment date change. Those details affect what a hotel can promise in an offer and what the guest ultimately agrees to buy.
The public draft gives hotel booking providers a concrete basis for reviewing that handoff. The most useful implementation evidence will be how systems preserve the approved rate and recover a reservation’s outcome when completion is delayed.
Start the conversation by posting the first comment