If a guest has paid but has no booking confirmation, hotel AI should verify the payment provider's record, check the reservation system, and create an owned exception if they disagree. It should not ask for another payment until reconciliation is complete, and it must not claim the booking is confirmed merely because the guest has a receipt.
There are two records and a delivery step
The payment provider may record success while the reservation update fails. The reservation may exist while the confirmation message fails to arrive. Or the guest may have a pending bank transaction rather than a completed hotel payment. Those cases require different actions.
Begin with the hotel's authorized transaction lookup. A screenshot can help locate a problem, but it should not replace verification. Avoid asking the guest to paste sensitive account or card information into chat.
Use a reconciliation decision table
| Verified payment | Reservation | Next action |
|---|---|---|
| Successful | Correct booking exists | Verify details and resend confirmation safely |
| Successful | Missing or invalid | Escalate for inventory and accounting reconciliation |
| Pending | Provisional booking | Explain pending status and the actual hold rules |
| Failed | No booking | Offer a supported retry after checking for duplicate attempts |
| Unknown | Unknown | Keep the case open; investigate without asserting success |
Protect the guest from paying twice
Before issuing a new link, inspect previous attempts associated with the enquiry and booking. A delayed provider notification can arrive after the guest retries. The system needs a way to recognize the original transaction and prevent a second attempt from being treated as unrelated business.
Repeated provider events should not create repeated payment entries or multiple confirmations. This is an operational requirement to test, not something a better-written prompt can guarantee.
Keep payment data out of ordinary conversations
The PCI Security Standards Council's messaging FAQ explains that handling card data through messaging brings the relevant systems into PCI DSS scope. Prefer a properly designed payment-provider flow and have the hotel's payment specialists confirm its responsibilities.
WhatsApp's messaging policy also restricts requesting sensitive payment identifiers. A support case should use the minimum reference information necessary for authorized lookup.
Test the partial failures
In a sandbox, complete payment and interrupt the reservation confirmation step. Then restore the connection. Inspect whether the system finds the existing transaction, creates one correct outcome, and records the recovery. Repeat with the booking saved but outbound messaging unavailable.
Also test an expired inventory hold. A successful payment does not create a room that another booking now occupies. The authorized team must resolve the exception using current availability and the hotel's approved process; the assistant should not promise an unapproved upgrade or refund.
Make the operator queue actionable
Include the property, enquiry reference, payment reference, amount and currency, current reservation state, and the last verified step. Assign an owner and track the time unresolved. Distinguish “confirmation resend pending” from “payment received with no valid reservation,” because the business risks differ.
Guest updates should say what has been verified and what is still being checked. A specific statement about investigation is more trustworthy than repeating “your booking is successful” while staff cannot find it.
Review Hotelary's payments overview and the rate-to-payment journey. Include these cases in your acceptance tests and use the outage recovery guide to verify replay and reconciliation after a disruption.
Sources and further reading
Sources reviewed on September 14, 2026. Check current vendor terms and policies before implementation. Examples and checklists are editorial guidance unless explicitly identified as reported research.
- PCI Security Standards Council's messaging FAQ — pcisecuritystandards.org
- messaging policy — business.whatsapp.com


