Testing payout or banking APIs from your laptop: the static IP problem

On the server, payouts work. On your laptop, the same request is rejected. You're trying to debug a live issue and you can't even reproduce the call. Here's what's going on and the safe ways around it.

Last updated 29 October 2026 · 4 min read

Testing a payout API from your laptop breaks for one reason: the provider only accepts live calls from IPs you've whitelisted, and your laptop isn't one of them. Home Wi-Fi, office Wi-Fi and your phone's hotspot all give you different addresses, and most of them change. You can fix it by testing in the right mode, by running the call from the server, or by sending your laptop's API calls out through a fixed address. If you go the last way, a static IP for payout APIs gives your laptop the same IPv4 your server uses. Here's how to choose.

First, check whether you even need the whitelist

A lot of this pain goes away once you know which calls are checked. RazorpayX applies IP allowlisting only in live mode, according to its allowlisting guide. If you're building or testing a new flow, do it in test mode with test keys. No whitelist, no real money, no risk.

Cashfree's production calls need either a whitelisted IP or a signed request. Check what their sandbox expects for your account before you assume either way.

So the laptop problem really shows up in two situations. You're debugging something that only happens in production, or you're running a small live test before launch. Both are exactly when you want to be careful.

Why your laptop's IP keeps failing

Run curl -4 https://ifconfig.co at home, then again at the office. Different answers. Restart the router after a power cut and run it again. Possibly a third answer. Many home connections in India are behind CGNAT too, so the address you see is shared with other customers of the same ISP.

You could add each of these to the whitelist. Please don't. RazorpayX caps you at 20 addresses. A dynamic home IP you added last month may belong to someone else today. And your payout account now trusts a coffee shop's Wi-Fi.

Option 1: run the call from the server

The simplest route is to SSH into the server that's already whitelisted and make the call there.

ssh deploy@your-server
curl -u "$KEY_ID:$KEY_SECRET" https://api.example-payouts.in/v1/balance

It's fine for one-off checks. It gets clumsy when you want to step through code in your editor, or use an API client on your laptop.

Option 2: tunnel through the server

If you have SSH access, you can borrow the server's address for your laptop's traffic with a SOCKS tunnel:

ssh -D 1080 -N deploy@your-server
# then, in another terminal:
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.co

That second command should print the server's IP. Point your test client at socks5://127.0.0.1:1080 and its calls leave from the server. Two downsides: the server's outbound IP has to be fixed in the first place, which isn't true on many cloud setups, and everyone who tests needs SSH access to a production machine. Most teams would rather not hand that out.

Option 3: a dedicated static IP for API calls

This is the setup we run at TrueIP. Your payout calls, from the server and from developers' laptops, go out through one dedicated IPv4 in Mumbai. You whitelist that one address with the provider. Each person sets the proxy in their client, and nobody needs SSH into production.

curl -x http://USER:PASS@HOST:PORT https://ifconfig.co
# prints the whitelisted IP, from any network

curl -x http://USER:PASS@HOST:PORT \
  -u "$KEY_ID:$KEY_SECRET" \
  https://api.example-payouts.in/v1/balance

In Python it's the proxies setting on a requests session. Most API tools have a proxy setting too. The connection stays TLS encrypted end to end, so we see the provider's hostname, not your keys or the payout details.

If you want testing kept apart from production, take a second IP for it, whitelist both, and give developers only the testing one.

Webhooks are a separate problem

Testing a payout end to end usually means receiving the status webhook too. That's the other direction: the provider calls a URL of yours. A static IP for outgoing calls doesn't help with it, because your laptop still can't be reached from the internet, and behind CGNAT it can't be reached at all.

For webhooks during testing, point the provider at a public URL on a staging server, or use a tunnelling tool built for local development. Either way, validate the webhook signature on every call, as Razorpay recommends even when you also filter by IP.

Testing live without getting burned

Whichever route you pick, a few habits save a lot of grief.

• Use the smallest amount your provider allows, to an account you control.
• Keep live keys in environment variables, never in code or a shared API collection.
• Use a separate key for testing if the provider lets you create more than one, so you can revoke it without touching production.
• Write down who made which live test, and when. Payout dashboards don't tell you which laptop a call came from.

Quick checklist

• Do as much as you can in test mode, where IP allowlisting usually doesn't apply.
• Don't add home or office Wi-Fi addresses to a live payout whitelist.
• For live debugging, run calls from the server, tunnel through it, or use a fixed IP that's already whitelisted.
• Check the IP with curl -x ... https://ifconfig.co before every live test.
• If the team tests from laptops often, give them a static IP for payout API testing rather than server access.

Keep reading