Choose the payment journey before you create the link.

Shared foundation

What every safe Payment Link journey has in common.

The business first confirms what the customer is paying for and records a stable internal reference. Waaru creates a hosted Razorpay Payment Link with the approved amount, description, expiry, and optional customer details. The customer opens Razorpay's hosted page to pay. A signed and deduplicated provider event normally supplies the outcome, while a targeted read reconciles the state when a critical result remains uncertain. That sequence keeps the financial decision grounded in Razorpay rather than in a screenshot, link click, browser return, or message saying paid. It also leaves the booking, store, calendar, or staff system responsible for the operational promise.

Hospitality

Hotel deposits begin with a room offer and hold window.

A property should confirm the dates, occupancy, room, rate, deposit amount, cancellation terms, and time limit before creating the request. The link reference should be recognisable to reservations and finance. Paid can move the stay toward confirmation only when the room decision is still valid. Expired, partially paid, or late-settling requests need a reservations owner who can recheck availability and explain the next choice to the guest.

• Best starting record: a booking enquiry or reservation reference
• Important time rule: payment expiry should match the room-hold decision
• Critical exception: payment succeeds after availability changes

D2C and ecommerce

Assisted D2C payments begin with an agreed order.

The brand should settle the product, variant, quantity, discount, tax, delivery charge, and payable amount before creating the link. Shopify or WooCommerce remains the source of order and stock truth. Razorpay owns payment. A shared order reference lets support reconcile the two records and hand the verified order to fulfilment without guessing from the customer's phone number or payment amount.

• Best starting record: a store order or controlled assisted-order reference
• Important time rule: price and stock validity should govern link expiry
• Critical exception: payment is verified but the intended order cannot be fulfilled

Appointments

Appointment deposits begin with a valid slot and policy.

The scheduling system or authorised team should first identify the service, practitioner when relevant, date, time, timezone, and deposit rule. A selected time is not necessarily a held time, so the message must explain when confirmation occurs. Link expiry should not outlive the slot hold. If payment arrives late, the service team needs both references before offering the original slot, an alternative, or a financial review.

• Best starting record: a calendar event, booking, or explicit slot hold
• Important time rule: payment expiry and slot hold must agree
• Critical exception: the deposit settles after the slot has been released

Product boundary

These guides cover hosted Payment Links, not every Razorpay product.

Razorpay separately documents a Payments on WhatsApp product. Waaru's current connector boundary on these pages is narrower: create, read, and cancel one hosted Payment Link; read one payment or refund; and receive selected verified payment, link, refund, or authorization events. It does not create refunds, subscriptions, recurring links, payouts, Route transfers, or UPI QR codes. Keeping this distinction visible prevents a use-case page from promising an action the connector does not expose.

Recovery design

Write the uncertain path before the success message.

Financial writes should carry an idempotency key, and ambiguous create or cancel results should not be retried blindly. Provider events can be duplicated or arrive out of order, so the handler verifies the signature, deduplicates the event, and reconciles the specific record when needed. The business then needs a named queue or person for late payment, partial payment, expired links, changed inventory, and customer-requested cancellation. A useful customer message says what is known, what is being checked, and who will respond. It should not claim payment failed merely because a webhook is delayed, and it should not repeat the charge while the original result is uncertain.

Setup

Connect once, then test each operational journey separately.

The merchant authorises the eligible Razorpay account through the Technology Partner OAuth flow. Provider webhook delivery and signature validation must be configured for the connected account. Use test mode to exercise create, paid, failed, expired, cancelled, and delayed outcomes with representative references. Then verify which queue receives each exception and what the customer sees. A hotel test should include an expired room hold. A D2C test should include changed price or stock. An appointment test should include a slot that becomes unavailable. Those checks prove more than a single successful low-value transaction because they validate the handoff around the payment.

Choosing a guide

Pick the page that matches the record your team already operates.

Use the hotel guide when reservations controls room offers and booking confirmation. Use the D2C guide when a store or assisted-order process controls the basket and fulfilment. Use the appointment guide when Google Calendar, Cal.com, another scheduling system, or staff controls a time slot. If none of those records exists, define the business process before adding payment automation. A Payment Link should attach to an accountable transaction, not create one by itself.