Start with the reservation system
The dev.ucp.lodging.booking draft describes a booking session after an offer has been discovered. It connects property, accommodation, rate plan, dates and occupancy to guest details, pricing and completion. A confirmed reservation follows completion, not the initial search. Lodging Booking overview.
Ask your provider to identify the system responsible for each operation. A website integration alone is not enough evidence that the underlying booking system can validate an offer, take payment and return a usable confirmation.
A checklist for the provider conversation
The checks below are our proposed assessment agenda. They are not a Google certification checklist or proof of eligibility.
1. Room, rate and guest mapping
Request an example covering one property, two room types and a refundable and non-refundable offer. Check identifiers against the reservation system. Test adult and child occupancy, a booker who is not staying, and a changed arrival date. Record unsupported combinations rather than silently substituting an offer.
2. Full price and payment timing
The draft separates the total stay cost from when payments are collected, including deposits and amounts paid at the property. Ask for a worked example that reconciles room charges, taxes, fees and payment schedules. Test a locally collected charge and an occupancy change; compare the displayed amount with the recorded reservation. Draft pricing model.
3. Availability, expiry and a changed offer
Ask what happens when the last room sells during checkout or the offer expires. Test a guest returning after a pause. Confirm that a changed price returns to guest review rather than being accepted silently. Specify how abandoned holds are released and how the guest continues after an unavailable offer.
4. Session operations and safe retries
The draft REST binding provides session creation, retrieval, update, completion and cancellation operations. Review authentication, idempotency and error responses with the provider. Lodging REST draft.
For the pilot, simulate a timeout immediately after submission. The test should establish whether the reservation exists before another attempt. Require a way for support staff to trace the request through to the reservation system without creating duplicate bookings or charges.
5. Payment, approval and handoff
Map the supported payment provider, token handling and any authentication challenge. Agree who owns the secure handoff when the flow cannot finish through the integration. Our proposed guest journey requires review and approval before booking. Google describes a final live price and availability check and channel-specific payment configuration. Google integration FAQ.
6. Cancellation terms and confirmation
The lodging cancellation extension models cancellation policies, including deadlines and penalties. Check the applicable time zone and terms against the rate plan. Cancellation Policy draft.
Test a booking near a cancellation deadline. Require a confirmation reference that hotel staff can locate, and specify how guests request changes, refunds or help. Distinguish abandoning an unfinished session from canceling a confirmed stay; do not assume a session-cancel operation provides post-booking servicing.
What to collect before scoping a pilot
- Provider contacts, relevant API documentation and a test environment.
- Sample offers and reservations, using synthetic guest details.
- A list of supported properties, currencies, occupancy rules and payment methods.
- Named owners for data quality, integration, payments and guest support.
- Written platform-access dependencies and acceptance criteria for the pilot.
Keep protocol readiness separate from Google onboarding. The public draft can inform preparation, while Google access remains waitlisted. The Shopping Playground simulates protocol messages in the browser; it is not a live hotel-booking demo or a lodging acceptance test. Google’s lodging-page image is labelled “Conceptual mock only”. Check Google’s current onboarding page.