How to whitelist an IP for payout APIs when your server IP keeps changing

You set up the payout API, tested it, it worked. Next morning every call fails. Here's how payout IP whitelisting works, how to find the address that actually matters, and how to stop it moving.

Last updated 29 October 2026 · 4 min read

Payout APIs move real money, so most of them only accept calls from server IPs you've registered in advance. To whitelist an IP for a payout API, you find your server's outbound address, add it in the provider's dashboard, and then make sure every payout call keeps leaving from that address. That last part is where most teams get stuck, especially on cloud servers. If you want it handled in one go, a static IP for payout API whitelisting gives your payout client a fixed IPv4. Below is the whole picture.

Why payout providers insist on IP whitelisting

The thinking is simple. If your API key leaks, the attacker still can't send transfers, because their requests come from the wrong address. Providers have made this stricter over time.

RazorpayX says it is mandatory to allowlist the IPs you use for payout-related API requests in live mode. That covers the Payouts APIs, including Contacts and Fund Accounts, plus Payout Links and Fund Account Validation. You can add up to 20 IPs. Their allowlisting guide asks teams on dynamic IPs to contact support.

Cashfree Payouts gives you two options for production calls: whitelist your server's IP, or sign each request with their public key. Their two-factor docs also say plainly that the IPv4 address has to be whitelisted, not IPv6.

Other providers vary. Some treat an IP check as an optional extra layer. Either way, assume you'll need a fixed IPv4 for production.

Find your server's real outbound IP

This trips people up all the time. The IP your domain points to is the address people use to reach your server. The payout provider sees the address your server uses to reach them. On a plain VPS they're often the same. Behind a load balancer, a NAT gateway or a container platform, they're usually not.

So ask from the server itself:

curl -4 https://ifconfig.co

Run it on every machine that makes payout calls. If you get different answers from different machines, each one needs to be whitelisted, or they all need to go out through one address.

Why the outbound IP keeps changing

On cloud setups the outbound address is often not something you chose. A few common ways it moves:

• An instance is replaced or rebuilt and comes back with a new public IP.
• Autoscaling adds a second server with its own address, and half the payout calls start failing.
• Serverless functions and managed platforms go out through shared address pools that change without notice.
• Kubernetes pods leave through whichever node they land on.

Office or home connections have their own problem. Most broadband here is dynamic, and plenty of it sits behind CGNAT, so the address changes after a router restart.

Three ways to keep one address

1. A fixed IP from your cloud provider

Most providers let you attach a fixed public IP to a server, or route a private network out through a NAT gateway with a fixed address. It works if every payout call runs inside that setup. It also costs extra, and if you move providers you go through whitelisting again.

2. Request signing, where it's offered

Cashfree's public-key option is meant for exactly this: servers whose IP can't be fixed. If you're only on Cashfree, it's worth a look. It doesn't help with providers that require an IP.

3. Route only the payout client through a dedicated static IP

This is the option we run at TrueIP. You get a dedicated IPv4 in Mumbai with its own proxy login. Set it on the HTTP client that talks to the payout API, and those calls always leave from that one address, whichever server or container sends them. The rest of your app's traffic is untouched.

import requests

payouts = requests.Session()
payouts.proxies = {"https": "http://USER:PASS@HOST:PORT"}

r = payouts.post("https://api.example-payouts.in/v1/payouts",
                 json=payload, auth=(KEY_ID, KEY_SECRET))

The connection to the provider stays TLS encrypted end to end. We see a destination host, not your keys or account numbers.

Adding the IP in the dashboard

Menus change, so check the provider's current docs, but at the time of writing:

• RazorpayX: My Account & Settings, then Developer Controls, then Share IP Addresses. Only the Owner or an Admin can do it, and it's confirmed with an OTP.
• Cashfree Payouts: the Payouts dashboard under Developers, then Two-Factor Authentication, then IP Whitelist.

Add the production address only. Keep a note of which server or service each whitelisted IP belongs to. Six months from now you'll be glad you did.

Don't mix this up with webhooks

Webhooks go the other way. The provider calls your server, from the provider's own addresses. If you filter incoming traffic, you allow their webhook IPs on your side, and Razorpay publishes that list. Your outbound static IP has nothing to do with it, and changing it won't affect webhooks. Keep validating webhook signatures too.

Quick checklist

• Run curl -4 https://ifconfig.co on every machine that makes payout calls.
• Whitelist IPv4 addresses. Cashfree says IPv6 isn't accepted, and RazorpayX doesn't mention it.
• Make sure new servers, containers and functions can't send payout calls from an unlisted address.
• Keep staging and production on separate IPs if your provider whitelists them separately.
• Pick one way to keep the address fixed: a cloud static IP, request signing, or a static IP for your payout API.

Keep reading