Indian guests expect UPI and familiar card checkouts. Razorpay is a common gateway choice for direct booking payments and deposits. A PMS-adjacent integration reduces spreadsheet reconciliation between “paid on link” and the folio.
01
Integrations
Section 01
Why Razorpay matters for Indian hotels?
Section 02
Which surfaces is the integration designed for?
When enabled, intended surfaces include:
- Booking-engine / direct booking deposits and prepayments
- Payment links for remaining balance before arrival
- Front-office collection flows that should post against the guest folio
- Refund / adjustment paths aligned to your finance SOP (policy-dependent)
Section 03
What is available only when enabled?
Gateway credentials, webhook endpoints, settlement mapping, and property-level entitlements are environment- and contract-specific. Do not assume every demo tenant has Razorpay live. Ask during onboarding which payment methods (UPI, cards, netbanking) your Razorpay account will expose.
Section 04
How should hotels prepare operationally?
Define deposit rules by rate plan, who can issue refunds, and how failed webhooks are retried. Train night audit on partial payments and chargebacks. Keep GST invoice timing aligned with your recognition policy when deposits convert to stay revenue.
Section 05
Where does this sit in the NISKA stack?
Payments support the agentic loop—reservations and Concierge can propose payable actions—but money movement still follows gateway and confirm rules. See product and pricing for packaging; confirm Razorpay enablement in implementation.