Take the deposit only after the stay details are agreed.

Before payment

Agree the stay, amount, and cancellation terms first.

Collect the property, check-in and checkout dates, guest count, room type, and the contact details the reservations team needs. Confirm availability from the property system or an authorised staff member. Then present the approved rate, deposit amount, expiry, and cancellation terms in plain language before asking for payment.

• Do not treat a completed enquiry form as confirmed availability.
• State whether the amount is a deposit, advance, or full payment.
• Show the last time the offer remains valid when inventory is being held.

Payment Link

Create one link for one booking reference.

Create the hosted Razorpay Payment Link only after the amount is approved. Attach a unique internal reference that the reservations and finance teams can recognise, keep the description specific to the stay, and set an expiry that matches the room-hold decision. The customer contact can be prefilled when the business has collected it for this transaction.

• Use the smallest currency unit required by Razorpay when setting the amount.
• Keep the internal reference stable across the conversation and payment record.
• Send the short URL in the same WhatsApp thread as the agreed booking summary.

Guest experience

Explain that payment opens on Razorpay's hosted page.

The Payment Link opens a Razorpay hosted page. The WhatsApp message should name the property, deposit amount, booking reference, and link expiry so the guest can check the request before opening it. Do not imply that a link click, screenshot, or customer message proves payment.

Verification

Confirm the reservation from the verified outcome.

A signed, deduplicated paid event is the normal trigger for the next step. If the event is delayed or the local result is uncertain, read the specific Payment Link or payment from Razorpay before issuing a confirmation. The confirmation should repeat the booking reference, dates, property, amount received, and the next arrival step.

• Paid can move the booking to the property's confirmation step.
• Partially paid needs the property's defined balance policy.
• Expired or cancelled should return the conversation to reservations, not create another charge silently.

Recovery

Give late payment and duplicate events a safe path.

Provider events can arrive more than once or later than the guest expects. Deduplicate them by provider identifiers and reconcile the current provider record before repeating a financial or inventory action. If the room is no longer available when a late payment settles, route the thread to reservations with the payment and booking references visible.

Cancellation

Keep refund decisions with staff and the stated policy.

The current connector can read one refund and receive refund processed or failed events, but it does not create refunds. A cancellation request should show the original booking and payment references to the authorised team. Staff can decide the eligible amount outside the workflow, then the conversation can continue when the provider reports the refund outcome.

Setup checklist

Test the exact hotel journey before guests see it.

Connect the eligible Razorpay account through the Technology Partner OAuth flow. In test mode, create a representative deposit link, complete and fail separate payments, let a link expire, and confirm that each verified event reaches the intended queue. Repeat one live representative payment only after the business has approved the message, booking policy, reconciliation owner, and recovery path.