How to Monitor Your Razorpay Checkout: The Complete Guide for Indian SaaS

Indian SaaS teams have a Razorpay monitoring problem that nobody talks about. It is not a Razorpay reliability issue — Razorpay is a solid platform. The problem is architectural: Razorpay's checkout works by loading a JavaScript SDK asynchronously from cdn.razorpay.com, after your server has already returned a 200 OK response. Your standard uptime monitor checks the server response. It never checks whether the JavaScript actually loaded and rendered the payment widget.

The result: your checkout can be broken for customers in Chennai, Bangalore, or Mumbai while your monitoring dashboard shows 100% uptime. In INR terms, a single weekend of undetected checkout failure for a mid-size Indian SaaS can mean ₹5–25 lakh in failed subscriptions and renewals.

This guide covers exactly how Razorpay's checkout works, the four most common monitoring gaps specific to Indian deployments, and how to set up proper Razorpay checkout monitoring with probe nodes in Mumbai and Hyderabad.

How Razorpay's checkout.js Works

Understanding the failure modes requires understanding Razorpay's architecture.

When you implement Razorpay on your site, your checkout page includes a script tag:

<script src="https://checkout.razorpay.com/v1/checkout.js"></script>

This script loads asynchronously from Razorpay's CDN — separate from your server, separate from your application. When your page loads:

1. Your server returns the HTML (200 OK) — this is what uptime monitors check ✓
2. Browser parses HTML and queues external resource loads
3. Browser fetches checkout.js from cdn.razorpay.com — this is the critical step ⚡
4. If step 3 succeeds: Razorpay payment modal is available to initialize
5. If step 3 fails (CDN down, timeout, network issue): no Razorpay modal, no payment

Step 1 and steps 2–5 are independent operations. A failure in step 3 is completely invisible to any monitoring tool that only runs an HTTP request to your server.

For UPI specifically, there is an additional step: Razorpay must communicate with NPCI's infrastructure to generate the QR code. A Razorpay checkout that renders the card payment form successfully can still fail for UPI users if the NPCI connection is degraded.

The 4 Most Common Razorpay Monitoring Gaps

Gap 1: CDN Availability — Is cdn.razorpay.com Reachable From Your Users?

The most common and most impactful gap. checkout.razorpay.com is served from a CDN with global edge nodes, but Indian users route through specific ISP peering arrangements that can cause intermittent failures.

Jio, Airtel, and BSNL have different peering relationships with CDN providers. A CDN edge serving checkout.razorpay.com that is fast and reliable from Airtel's network in Mumbai can be slow or unreachable from BSNL broadband in Tier-2 cities.

How to monitor this: Use the free Checkout Defender tool to test from the Mumbai probe (AWS ap-south-1). This probe connects via the same ISP infrastructure as your Indian users. If checkout.razorpay.com loads in under 500ms, you are fine. Over 1000ms is a warning. A timeout or error means your checkout is broken for significant portions of Indian traffic.

Gap 2: Checkout Modal Render Check

Loading checkout.js successfully does not guarantee the payment modal appears. Your application code calls Razorpay() with your configuration object. If this call fails — wrong API key format, missing currency field for newer API versions, JavaScript error before the call — the modal never opens.

The payment button is present. Users click it. Nothing happens. The checkout.js script loaded fine. The application code that calls it did not.

How to monitor this: A proper flow monitor opens your checkout page in a real browser, clicks the payment button, and asserts that the Razorpay modal appears (checking for the presence of the iframe or overlay element Razorpay injects). This is the check that catches initialization failures and API version issues.

Gap 3: UPI QR Code Generation

Razorpay's UPI option requires additional infrastructure beyond the base checkout.js script. When a user selects UPI, Razorpay generates a unique UPI QR code and VPA (Virtual Payment Address) in real time. This operation connects to NPCI's VPA lookup infrastructure.

A checkout that passes all widget render checks can still fail for UPI users if:

• NPCI infrastructure is degraded
• Your Razorpay account's UPI configuration is incorrect
• The amount parameter violates UPI limits (minimum ₹1, maximum ₹1,00,000 for certain UPI apps)

Given that UPI represents 40–60% of digital payments in India, a UPI-specific failure is a majority-payment-method failure.

How to monitor this: Include a UPI flow step in your checkout monitor that selects the UPI payment method and verifies the QR code or VPA appears within a reasonable timeout.

Gap 4: Post-Payment Redirect Verification

The most critical and most commonly missed gap. After a Razorpay payment completes (or is cancelled/failed), Razorpay triggers your handler callback or redirects to your callback_url. If this callback fails:

• Your server may not record the payment as completed
• The user may be stuck on Razorpay's confirmation page with no redirect
• Your order fulfillment may not trigger (subscription not activated, product not delivered)

Standard uptime monitors check your checkout page. They never check whether the post-payment callback correctly triggers your order fulfillment logic.

How to monitor this: Use a test Razorpay payment in test mode (with test card 4111 1111 1111 1111) as part of a scheduled flow monitor. Verify the callback URL receives the payment data and your order confirmation page loads.

Step-by-Step Razorpay Checkout Monitoring Setup on PingSLA

Step 1: Quick sanity check (free, 60 seconds)

Go to pingsla.com/tools/checkout-defender and enter your checkout URL. This gives you an immediate report on whether your Razorpay checkout is currently rendering correctly from Mumbai.

Step 2: Set up continuous monitoring (5 minutes)

1. Log in to app.pingsla.com
2. Click New Monitor → Flow Monitor
3. Enter your checkout URL
4. Add flow steps:
   • Navigate: go to https://yourstore.in/checkout
   • Wait: wait for #razorpay-button or your payment trigger element (up to 5 seconds)
   • Click: click the payment button
   • Assert: assert that .razorpay-container or iframe[src*="razorpay.com"] is visible within 8 seconds
5. Set interval: 1 minute
6. Select regions: Mumbai (ap-south-1), London, N. Virginia — covering Indian users and global fallback
7. Enable mobile viewport test (check the toggle) — tests on 375px viewport
8. Configure alert: WhatsApp (recommended for Indian teams) or Slack/email

Step 3: Configure probe regions for Indian traffic

For products primarily serving Indian customers, add these probes:

Step 4: Set up WhatsApp alerts

WhatsApp is the highest-read alert channel for Indian engineering teams. In PingSLA's alert configuration, add a WhatsApp contact number (Growth plan and above). When your Razorpay checkout fails, the alert arrives on WhatsApp within 60 seconds of the failure being detected.

At 2 AM when your on-call engineer has 247 unread Slack messages, WhatsApp is what actually gets read.

Razorpay Webhook Monitoring

Beyond the checkout UI, Razorpay sends webhook events to your server for payment completion, failure, and refunds. These webhooks are critical for order fulfillment. A webhook endpoint that returns 200 OK but doesn't actually process the event (due to a signature validation bug or handler exception) will cause Razorpay to mark the delivery as successful while your orders go unfulfilled.

Use the free Webhook Checker tool to test your Razorpay webhook endpoint:

# Razorpay webhook test payload structure
{
  "entity": "event",
  "account_id": "acc_test",
  "event": "payment.captured",
  "payload": {
    "payment": {
      "entity": {
        "id": "pay_test123",
        "amount": 50000,
        "currency": "INR",
        "status": "captured"
      }
    }
  }
}

Your webhook endpoint should return 200 within 5 seconds (Razorpay's timeout) and process the payment event. The Webhook Checker sends this payload with the X-Razorpay-Signature header so you can verify your HMAC validation logic is working correctly.

PingSLA Probe Locations in India

All Indian probes connect via AWS Direct Connect to major Indian ISP peering points, providing representative latency for Jio, Airtel, and BSNL users.

Why does Razorpay checkout work in my browser but fail for customers?

Your browser has Razorpay's JavaScript cached from previous visits. Your office network may have a different CDN routing path than your customers' ISPs. Test using an incognito window on a mobile data connection (not WiFi) from your production URL — this more accurately represents customer conditions. Better yet, use the Checkout Defender tool which tests from a clean browser environment with no cache.

How do I test Razorpay in test mode without real payments?

Razorpay provides test credentials and test card numbers. For Razorpay test mode, use API key starting with rzp_test_. Test card: 4111 1111 1111 1111, any future expiry, any CVV. For UPI test: use success@razorpay as the VPA. PingSLA's flow monitors support test mode payment flows for continuous checkout testing without real transactions.

What is the difference between monitoring Razorpay checkout from Mumbai vs other regions?

Razorpay's CDN infrastructure serves Indian users from nodes peered with Indian ISPs in Mumbai and Chennai. Testing from a US or European probe does not test the actual CDN path that Indian users experience. A Mumbai probe that connects via Indian ISP infrastructure will catch CDN routing issues, NPCI connectivity issues, and latency spikes that are invisible from non-Indian probes.

Does PingSLA support UPI QR code monitoring?

Yes. PingSLA's flow monitors can navigate to the UPI payment option within a Razorpay checkout modal and verify that the QR code or VPA appears within a configurable timeout. This is available on Growth plan and above.