Tie the deposit to a real slot, service, and booking policy.

Policy first

Define when a deposit is required and what it confirms.

Write the rule before automating it. Specify which services require a deposit, the amount or percentage, how long the slot is held, when an appointment becomes confirmed, and how cancellation or rescheduling is handled. The WhatsApp message should state the applicable rule without turning policy text into hidden fine print.

Availability

Read the calendar before requesting payment.

Let Google Calendar, Cal.com, or the business's chosen scheduling system own the current slot. Collect the service, location or mode, practitioner when relevant, date, time, timezone, and customer details required for the booking. If the system cannot safely hold the slot, tell the customer that confirmation is pending instead of presenting payment as a guarantee.

Payment Link

Match link expiry to the slot-hold decision.

Create the hosted Razorpay Payment Link with the appointment or hold reference, service description, deposit amount, customer details, and an expiry that does not outlive the intended hold. Send the link with the exact slot and policy summary in the same WhatsApp thread.

• The booking reference should be recognisable to the service team.
• The amount must match the policy shown to this customer.
• The customer pays on Razorpay's hosted page, then returns to the conversation for the next message.

Confirmation

Use the verified result to complete the booking path.

A signed, deduplicated paid event can move the journey to confirmation. If the event is missing or ambiguous, read the specific Payment Link or payment from Razorpay. Before sending the final confirmation, make sure the appointment reference still points to the intended slot and customer.

• Confirm the service, date, time, timezone, location, and amount received.
• Send preparation or arrival instructions only after the booking state is settled.
• Keep the human queue visible when payment succeeds but the slot cannot be confirmed.

Expiry and failure

Recheck the slot before replacing a payment request.

When a link fails, expires, or is cancelled, the original slot may no longer be available. Return to the calendar or scheduling owner before creating another link. A partially paid result should follow a written business rule and normally requires staff review rather than an automatic balance request.

Changes

Keep rescheduling separate from the financial decision.

A reschedule first changes the booking decision, then determines whether the existing deposit can be carried forward under the business policy. A cancellation first identifies the appointment and payment records, then routes the financial review. The current Razorpay connector can read refund status and receive refund events, but it cannot create a refund.

Setup checklist

Test timing, not only the happy path.

Connect Razorpay through the Technology Partner OAuth flow and connect the selected scheduling provider separately. Test a paid deposit, a failed attempt, an expired link, a late paid event, an unavailable slot, and a customer-requested reschedule. The owner for each exception should see the customer, appointment, link, and payment references together.