RazorpayX IP Allowlisting for Live Payout APIs

A stable outbound IP gives your cloud application a predictable network identity when it calls an IP-restricted API. For a RazorpayX launch, that makes the production checklist much clearer: identify every process that makes API requests, give those requests an approved outbound route, and verify the route before enabling live payout workflows.

QuotaGuard can provide that fixed-egress layer for proxy-compatible applications. You can keep your application on its current hosting platform and route the selected HTTPS requests through the proxy instead of changing your website's public address or building a new network around the whole application.

Why a working test integration can still fail at launch

Razorpay requires source-IP allowlisting for live payout-related APIs. Its documented scope includes Contacts, Fund Accounts, Payout Links, and Fund Account Validation. This control excludes Vendor payments, Payroll, and Dashboard payouts; Payment Gateway allowlisting follows a separate support route. See Razorpay's allowlisting documentation.

The practical implication is important: a successful test-mode request does not demonstrate that the production caller's source address is authorized. Treat application behavior and production network authorization as separate checks.

Imagine an application with three parts. Its web process accepts an internal payout request. A background worker submits the approved operation. A scheduled job later reconciles records. A developer tests the web application from a laptop and sees no problem. That laptop test tells you very little about the worker's deployed network path.

A better launch question is: Which process opens the connection to Razorpay, and which public source IP does that connection use? Answer it for the worker and scheduled job as well as the web process.

Identify the address that the API actually sees

A cloud application can have several addresses, each serving a different purpose:

• Website or load-balancer IP: receives visitors coming into your application.
• DNS record for your domain: directs those visitors toward the website.
• Webhook endpoint: receives incoming events from another service.
• Developer's public IP: identifies a laptop or office connection during a local test.
• Outbound egress IP: identifies the network connection your application opens to a remote API.

For source-IP restrictions on your application's API requests, the final item is the one to investigate. Updating website DNS does not configure your HTTP client's outbound path. An inbound proxy protecting a webhook does not automatically route an unrelated outgoing API call.

For an explicitly proxied HTTPS request, the intended path is:

Web process, worker, or scheduled job
  -> configured outbound HTTPS client
  -> QuotaGuard proxy
  -> Razorpay API

A request made by a different client can still use another path. This is why setting an environment variable is only part of the implementation: the library making the connection must consume that configuration.

Choose the smallest network change that meets the requirement

If your application already has a stable, approved outbound route, use it. A managed cloud network or existing egress gateway may already supply the addresses your team needs. There is no reason to add a proxy simply because an API has an allowlist.

An explicit outbound proxy is useful when the application is on shared or dynamic hosting, when only selected integrations need fixed egress, or when the team wants to manage routing at the HTTP-client level. The benefit is focused configuration: requests that need the fixed route use it, while unrelated traffic keeps its existing behavior.

Make the decision against the actual requirements:

1. Does the destination accept the proposed IP addresses and infrastructure arrangement?
2. Can the application's HTTP client or SDK use an authenticated proxy?
3. Can every relevant worker and scheduled job receive the configuration?
4. Does the route meet the account's geographic and security requirements?
5. Who owns monitoring, secret rotation, and the production cutover?

Confirm these points for your RazorpayX account before choosing a deployment route. Fixed egress solves the source-address problem; it does not replace destination approval, API credentials, or account permissions.

Make a caller inventory before changing configuration

Write down each process that makes the relevant API calls. A short inventory often catches problems that are otherwise mistaken for intermittent provider failures.

For each caller, record the deployment environment, runtime, HTTP library or SDK, secret source, and owner. Include queue consumers, scheduled jobs, administrative jobs, and any alternate deployment that can take over traffic. Record separate regions or services individually when their networking differs.

Consider this example:

Production web service
  Receives application requests; does not submit payout operations.

Production payout worker
  Opens API connections; needs the approved egress configuration.

Production reconciliation job
  Opens its own API connections; needs its own route verification.

Developer laptop
  Used for development; does not validate either production process.

Keep the inventory close to the deployment configuration. When someone adds a second worker, they should know that the network check belongs in the change review.

Configure the proxy where the connection is made

Create a dedicated client or transport for the integration. Read the proxy URL from the server-side secret store, reject a missing configuration, and pass that client to the code that makes the request.

Do not assume that a framework client, a third-party SDK, and Node's built-in fetch all interpret the same proxy settings. A successful diagnostic using one client does not prove that a different SDK follows the same route. Inspect the SDK's documented transport extension point, or use a supported direct HTTP implementation if that is appropriate for the integration.

Good routing behavior is deliberate:

• The protected client refuses to send when its required proxy configuration is absent.
• Destination TLS certificate verification stays enabled.
• Redirects are reviewed rather than followed automatically to another host.
• Connection and response timeouts are bounded.
• A failed proxied request does not trigger a direct retry.
• Other application clients are not silently reconfigured.

This gives failures a useful meaning. A missing secret fails in the application, while a proxy connection problem remains a network problem. Neither should quietly change the route for a financial operation.

Keep the connection address separate from the allowlist addresses

Your QuotaGuard dashboard provides both a proxy connection URL and the subscription's static IP addresses. Use the URL in the client configuration, and use the static addresses for the destination allowlist. The connection-details guide explains where to retrieve them.

Allowlist both assigned addresses for the selected subscription. QuotaGuard provides a pair so that connections can use either endpoint; a single observed result is not the complete pair. See why there are two addresses.

Do not substitute the IP returned by resolving the proxy hostname. The hostname is how your client reaches the proxy service. Your dashboard's assigned addresses are the information to use for the approved outbound route.

Store the full connection URL as a secret. It contains proxy credentials and should not appear in browser-delivered code, source control, screenshots, support transcripts, or ordinary application logs.

Verify the network without creating a live payout

Start with a non-mutating source-IP diagnostic from the deployed environment. The diagnostic should make a simple HTTPS request through the same proxy-aware transport and compare the returned source IP with the dashboard pair.

A passing result establishes a narrow but useful fact: that request left through an expected address. It does not establish that Razorpay has accepted the account's configuration, that every other process uses the proxy, or that a payout will complete.

Run the check separately in the actual web service, worker, and scheduled runtime that make API requests. Include the deployment identifier and process name in your private test record. Repeat it after a redeployment or process restart so that you are checking the durable configuration rather than a temporary shell setting.

Do not create a payout, contact, fund account, or validation request just to discover the source IP. Keep the networking check separate from the application's authorized financial testing process. If a provider-side verification is needed, agree on an appropriate non-mutating operation and the necessary access with the account owner.

For a redundant pair, repeated successful diagnostics may still show only one address. That is not a reason to remove the other address from the allowlist or to force an outage. Verify the configured pair and use a planned, authorized procedure for any failover exercise.

Troubleshoot the failing layer

Razorpay's error documentation distinguishes a source-IP rejection from authentication and business-operation errors. Match the returned description to the RazorpayX error reference before changing the network.

An explicit IP rejection: compare the failing caller's observed egress with the approved addresses. Check for a worker that bypasses the proxy, an old deployment using different credentials, or a subscription mismatch.

Proxy authentication failure: check the proxy credential source and rotation history. These are separate credentials from the destination API's keys. Do not paste either secret into a support message.

A timeout or TLS error: investigate connectivity, DNS, the configured proxy endpoint, and the trust configuration. Disabling certificate verification does not establish that the application is talking to the intended service.

An authentication, permission, payload, or payout-state error: keep the source-IP check as evidence, then investigate the application or account condition identified by the provider. Changing an allowlist is not a general repair for API failures.

A failure after a deploy or only in background jobs: inspect the caller inventory first. The web service and worker may have separate secrets, deployment versions, startup configuration, or client factories.

Avoid blind retries while diagnosing. A timeout does not by itself tell you whether a state-changing operation reached the provider. Follow the provider's operation-specific reconciliation and idempotency guidance before retrying a financial request.

Understand the security boundary

For an HTTPS destination, QuotaGuard Static supports CONNECT tunneling: the application negotiates destination TLS through the tunnel, and the HTTPS payload is not decrypted by the proxy. See QuotaGuard's outbound HTTPS explanation.

The connection to the proxy is a separate consideration. With an http:// proxy URL, the initial proxy connection and proxy authentication are not protected by TLS on that hop. Destination HTTPS remains necessary. Review the proxy transport, credential handling, data route, and applicable security requirements together rather than selecting a product from the word “payments” alone.

A fixed address also does not become an application credential. Continue to protect API keys, enforce authorization in the application, and redact sensitive financial data. If your requirements include dedicated infrastructure, evaluate the dedicated option explicitly: standard shared static addresses are not exclusive to one customer. The current plan comparison distinguishes shared and dedicated arrangements.

A launch checklist the team can use

Before enabling the live workflow, confirm that the team can answer these questions:

• Which production processes open the API connections?
• Which client or transport is used by each process?
• Where is its proxy secret stored, and how does a rotation reach running processes?
• Do both assigned egress addresses appear in the approved configuration?
• Has a non-mutating diagnostic passed from each deployed caller?
• Has the account owner confirmed the intended network arrangement?
• Are financial-operation testing, retries, and reconciliation covered by a separate release plan?
• Is rollback a controlled pause or a previously approved route, rather than an automatic direct connection?

The goal is a repeatable production path. Once the route is explicit and observable, deployments and worker changes become easier to review, and network failures are easier to distinguish from application failures.

Talk with QuotaGuard about the hosting platform, HTTP client, and outbound requirements for your application. Start with the callers and the destination's requirements, then choose the smallest routing change that fits.