Troubleshoot Outbound IP Problems in a RazorpayX Integration

Start with the failing request’s caller and error description. This runbook helps separate source-IP authorization, proxy connectivity, API authentication, and application-state problems without using a live financial operation as a diagnostic.

Capture the process name, deployment version, time, destination host, HTTP status if available, and a sanitized error description. Exclude API keys, proxy URLs, account data, and payout payloads from the working notes.

The response explicitly rejects the source IP

Razorpay documents this error:

Transactions from this IP are not allowed. Contact support for help.

The RazorpayX error reference associates it with a caller whose source IP is not allowlisted.

First identify which process produced the failed request. Run a non-mutating source-IP diagnostic through that process’s actual proxy-aware client, or a transport-equivalent test. Compare the result with the assigned dashboard pair and the provider-side configuration.

If the observed source is outside the pair, investigate the route rather than repeatedly editing the allowlist. If it matches the pair, check the account and environment, confirm the saved configuration, and provide the account owner or provider support with sanitized evidence. A matching IP alone does not establish that every other account requirement has been met.

Do not infer the cause from the HTTP status alone. Use the response description and provider documentation; several unrelated failures can share a status family.

Local tests pass but the deployed application fails

A laptop, CI runner, web container, and background worker can all use different networks. Identify where the passing test ran and where the failure occurred.

Check that the production service received the intended proxy URL, that it restarted or redeployed as required, and that the actual HTTP library consumes the setting. Inspect for an old deployment or a different secret name. Use the service’s secret-management interface to compare configuration references without printing secret values.

Run the diagnostic inside the deployed caller, not just in a build step. A source-IP check from CI establishes CI egress, which may be unrelated to the running service.

The web process works but a worker or cron job fails

Treat the worker as its own deployment. Confirm its secret attachment, startup configuration, client factory, and library version. A shared repository does not guarantee a shared environment.

Look for a code path that constructs a fresh direct client inside a job. Replace only that integration’s transport configuration through the normal application review process. Do not globally proxy unrelated jobs in an attempt to hide an incomplete caller inventory.

After the change, verify the worker and the scheduled job independently. Record the process names alongside their results so the next release can repeat the same checks.

Failures appear intermittent

Group the failures by caller, deployment, and time before assuming that the provider is inconsistent. Typical routing hypotheses include one unconfigured worker, an old deployment still consuming a queue, a scheduled task with different secrets, or only one member of an egress pair being accepted.

Check that both assigned addresses are in the intended allowlist. Repeated diagnostics can use the same address because of connection reuse or routing behavior; they do not prove the other address is unnecessary.

Do not force a production outage to prove failover. If the team needs a failover exercise, define the test and rollback procedure with the relevant service owners and run it under explicit authorization.

The proxy returns an authentication error

Check the QuotaGuard connection URL and selected subscription. A proxy authentication failure concerns the proxy credentials, not the destination API’s credentials.

Look for a rotation that updated the web service but not a worker, a malformed manually assembled URL, or stale configuration in a long-lived process. Prefer the complete URL supplied by the dashboard rather than rebuilding it from unescaped pieces.

Do not enable verbose logging that exposes the full URL. If a secret was disclosed, follow the approved rotation process, deploy the replacement to every caller, and verify the new configuration without logging it.

The request times out before a usable API response

Separate connection to the proxy from the HTTPS tunnel and the destination request. Check the proxy host and port from the actual runtime, outbound network restrictions, name resolution, and client timeout configuration.

Use the non-mutating diagnostic to narrow the issue. A successful IP check shows that its particular route worked, but a destination-specific block or failure can still exist. A failed IP check is also not proof that Razorpay is unavailable.

Do not let an exception handler retry directly. That changes the route at the exact point where the application has lost visibility into the outcome. A financial operation with an uncertain response requires reconciliation under its own documented retry rules.

TLS verification fails

Check the destination hostname, certificate trust store, runtime clock, and any approved corporate interception or custom CA configuration. Keep verification enabled while investigating.

For the Python example, trust_env = False intentionally prevents ambient environment settings from changing the client. If your environment requires an approved custom CA file, configure it explicitly using the client’s documented option. Do not use verify=False or disable Node’s certificate verification as a production fix.

The destination TLS session and the transport to the proxy are different layers. An HTTP proxy URL can carry an HTTPS CONNECT tunnel, but the initial proxy hop itself is not TLS-protected. Review the required architecture rather than treating all URLs containing “http” as the same connection.

The IP diagnostic works but the SDK still fails

Compare the two transports. An example using Node’s https.get with an agent does not configure built-in fetch or a vendor SDK. A Python Session passed to one helper does not affect code that creates another Session.

Find the SDK’s documented way to supply a transport, adapter, agent, or proxy setting. Add route verification at that boundary. If the SDK offers no suitable extension, evaluate a supported direct HTTP integration or another approved network architecture rather than assuming global proxy variables will work.

Keep authentication and request semantics intact when changing the transport. Do not treat a networking change as authorization to rewrite financial-operation logic.

An authentication or permission error remains

Once you have evidence of the correct route, investigate credentials, account permissions, the selected environment, and the specific operation’s requirements. Use the provider’s error description to select the next check.

Proxy credentials and destination credentials are independent. Swapping them, sending both to a diagnostic endpoint, or weakening the allowlist will not repair an account authorization problem.

A payload or payout state error remains

Review the request against the operation’s current documentation and reconcile any existing operation before retrying. The source address does not determine whether a request body is valid or whether an operation can move from its current state.

Preserve the application’s idempotency behavior during network changes. Do not create new financial requests to find out whether an earlier request succeeded.

The observed IP is correct but access is still denied

Recheck the provider account, environment, saved allowlist, and precise error description. Confirm that the failing request used the same reviewed transport as the diagnostic. Then escalate with a concise, sanitized record:

Account reference approved for support:
Environment and deployment identifier:
Caller and HTTP client:
Failure timestamp with timezone:
Destination host and method:
HTTP status and sanitized provider description:
Observed source IP from that caller:
Assigned pair and saved allowlist comparison:
Recent deployment or secret rotation:

Do not attach financial payloads, customer personal data, full headers, authenticated URLs, API secrets, or raw stack traces without reviewing and redacting them. Share only the information needed to investigate through the approved support channel.

Restore service without bypassing the intended route

A safe recovery is a controlled pause, queue handling under the application’s design, or a reviewed return to a previously approved egress configuration. Avoid removing the allowlist or enabling an automatic direct fallback to get a green health check.

After recovery, repeat a non-mutating check from each affected caller and document what changed. Keep the network result distinct from the application’s financial reconciliation result. Both can matter, but they answer different questions.

Download the reference examples · Integration overview