Razorpay Payment Error: ERR_NAME_NOT_RESOLVED Fix

Applies to: WHMCS invoices using the Razorpay payment gateway module (shown as "Credit/Debit Cards / Wallet / UPI" or similarly labelled)

If a customer tried to pay a WHMCS invoice through Razorpay and the browser console (press F12) showed net::ERR_NAME_NOT_RESOLVED for a domain ending in razorpay.com or fpjs.io, or an error reading Razorpay is not defined, the Pay button did not actually fail: something blocked the Razorpay checkout script from loading before it could even run. In almost every case this is an ad blocker or a DNS filter (AdGuard Home, Pi-hole, NextDNS) on the customer's own device or network, not the WHMCS site itself. This applies to any WHMCS installation using Razorpay, not just ours.

What we saw

We run WHMCS with the Razorpay gateway module ourselves at Ucartz, and a customer reported exactly this: the Pay button did nothing after selecting the Razorpay option. Their browser's developer console (F12, Console tab) showed:

• net::ERR_NAME_NOT_RESOLVED against checkout.razorpay.com, lumberjack-metrics.razorpay.com, and ap.api.fpjs.io
• Uncaught ReferenceError: Razorpay is not defined
• The payment window not opening at all

ERR_NAME_NOT_RESOLVED is a browser-level DNS error: it means the device could not even look up the address for that domain, before any connection to Razorpay or to the WHMCS site was attempted. That is the key clue that points away from the server and towards something blocking DNS lookups on the customer's own side.

What we checked first

Before assuming it was the customer's own network, we ruled out the usual server-side causes on our own installation:

• PHP bytecode caching (OPcache): not installed on our web server, so it could not have been serving stale code.
• Server error logs: nothing related logged on our end, since a blocked script is enforced by the browser and never reaches the server.
• Payment gateway logs: no failed transaction attempt recorded for the affected invoice, meaning the block happened before any payment request was sent, and no payment was taken.
• A live test payment: we opened a different unpaid invoice ourselves, selected the Razorpay option, and the checkout window loaded correctly with no errors.

That last check matters: it confirmed our WHMCS checkout page itself was working, so the cause had to be something affecting that one customer's connection, not the site.

What we found

Two things can cause this on a WHMCS site using Razorpay, and it is worth knowing both.

A site-side misconfiguration. Most commonly an overly strict Content-Security-Policy header that blocks checkout.razorpay.com and its supporting scripts for everyone. We hit this ourselves at one point, identified it, and corrected it, confirmed by a real customer payment going through afterwards on the same invoice. If this is a sitewide problem, every customer trying that gateway will be affected, not just one.

Ad blockers or DNS-level filtering on the customer's own device or network. This is the more common, ongoing cause, and produces exactly the ERR_NAME_NOT_RESOLVED error above. Software such as AdGuard Home, Pi-hole, NextDNS, or a browser ad blocker often blocks Razorpay's supporting domains by default, since they resemble tracking or analytics domains. In the case above, the customer confirmed this themselves after checking their own router's DNS filter.

To tell which one applies: test the same invoice yourself, or ask another customer to try, on a different network with no ad blocker or DNS filter active. If it works there, the problem is local to that one customer's network, not the site.

Domains Razorpay's checkout needs to reach

• checkout.razorpay.com
• api.razorpay.com
• checkout-static-next.razorpay.com
• lumberjack-metrics.razorpay.com
• ap.api.fpjs.io

If you run a WHMCS site yourself and want to rule out a site-side cause, check that your Content-Security-Policy headers, if any, allow these domains in script-src and connect-src.

Fixing it on the customer's side

AdGuard Home:

1. Open the AdGuard Home dashboard and find the custom filtering rules.
2. Add an exception rule for each domain above, in the form @@||domain^, for example @@||checkout.razorpay.com^, according to AdGuard Home's own documentation.
3. Save, then reload the invoice page and try again.

Pi-hole:

1. Go to Group Management, then Allowlist, in the Pi-hole admin page.
2. Add each domain above as an exact allowlist entry.
3. Save, then reload the invoice page.

Browser ad blocker (uBlock Origin or similar):

1. Open the extension on the invoice page and disable it for the site, or add the domains above to its allowlist.
2. Reload the page and try again.

Quickest check: temporarily turn off the ad blocker or DNS filter entirely, retry the payment, then turn it back on once it has gone through.

Still not working?

If you are a Ucartz customer, open a support ticket and include your browser's console output (F12, Console tab, copy anything shown in red). We run WHMCS and Razorpay ourselves day to day, so we can usually tell quickly whether it is a site issue or a local filter.