Locking a Payment API Key to an IP Address

Payment providers increasingly let you bind an API key to the addresses it may be used from, so a stolen key is useless off your network. Stripe calls this an access policy. It is one of the highest-value controls available on a payment integration and almost nobody turns it on, because dynamic infrastructure has no address to bind to. Here is how the control works, what it needs from you, and how to get an address stable enough to use it.

The control, and why it is worth more than it looks

A leaked secret key is the worst thing that can happen to a payment integration: it is bearer credential, it works from anywhere, and the first sign is usually the money. Every other mitigation — rotation, vaults, scoping — reduces the blast radius or the window. Binding the key to a source address removes the "from anywhere" part entirely.

Stripe's documentation is direct about it. Its access policies let you restrict a key, and it says plainly: "Stripe recommends configuring access policies on all live mode keys." If a request arrives with a key from a source the policy does not allow, "Stripe blocks the request and notifies you" — so you find out about a compromise from an alert rather than from a reconciliation.

Two policy types are offered. IP addresses: "Restrict access to one or more specific IPv4 addresses or CIDR ranges. Use this approach if your servers have fixed IP addresses." Advanced: restrict by autonomous system number and country, and block source categories including anonymous VPNs, public proxies, residential proxies and Tor exit nodes. Quoted from Stripe's API keys documentation, read 2026-09-17. Note also that Stripe has retired the older per-key IP restrictions in favour of policies — if you read an older article telling you to set IP restrictions on the key itself, it is out of date.

Other providers have their own versions of this, under names like IP allow-list, trusted IPs, or source restrictions. The mechanics differ; the shape does not.

Why it is usually left off

Because the control needs a fixed address and most modern deployment does not have one. Containers get a new address on every schedule. Serverless functions egress from the provider's shared pool. Autoscaling groups come and go. Even a fixed cloud instance loses its address the day it is replaced.

The tempting workaround is to allow your cloud provider's published range, which permits every other customer of that provider and is not a meaningful control. Stripe's Advanced policy type is more honest about this: it lets you allow an ASN — so you can say "requests may come from Amazon, in the United States, and not from Tor" — which is a real narrowing, and is still a very large set of machines that are not yours.

The version of this control that is actually strong is the one with your own address in it.

What "a fixed address" has to mean here

Three properties, and a policy is only as good as the weakest one.

Stable. It must not change on deploy, restart, scale or provider maintenance. If it can change without you doing anything, the control's failure mode is a total payment outage at an hour you did not choose.

Yours alone. A shared egress address technically satisfies the policy and quietly defeats it: everyone else behind that address is inside your allow-list. It is worth reading Stripe's Advanced policy options again with this in mind — public proxies and residential proxies appear there as source categories you can block. That is the industry's view of shared proxy egress, written down by a payment company.

Attributable. When a security review asks who holds the address, there should be an answer that can be checked in a public registry rather than taken on trust.

How to turn it on without an outage

1. Get the stable address first and have your integration already using it, before you write any policy.
2. Measure the source address, do not assume it. From the machine that will make the calls: curl -4 https://api.ipify.org, then confirm with a second service. Check IPv6 separately — if your client can prefer v6 and the policy only names v4, you have built a delayed outage.
3. Start in the sandbox. Create the policy, apply it to a test key, and run your full payment path against it.
4. Apply it to a live key during business hours, never last thing on a Friday, and watch the request logs.
5. Write down what happens when the address must change — who updates the policy, and in what order relative to the address change. Update the policy first; an address in an allow-list that you are not yet using is harmless, an address you are using that is not in the list is an outage.
6. Keep a documented break-glass path: how you would remove the policy if you lost access to the network the policy names. Locking yourself out of your own payment provider is a real failure mode of this control.

Where TunnelNet fits

We give you a dedicated static IPv4 address from 23.187.152.0/24, announced by AS396500, our own autonomous system. Your machine keeps running where it is; a WireGuard tunnel attaches the address to it, and outbound traffic leaves from that address.

That satisfies all three properties above. It is stable across redeploys because it is not tied to an instance. It is dedicated, so nobody else's traffic is inside your policy. And it is attributable: a reviewer can look up the block and the ASN in a public routing database and see who announces it, without asking either of us. If the provider supports ASN-based rules, AS396500 is a set containing our customers rather than a cloud provider's entire fleet.

$20/month on TunnelNet Full. If this is a payment integration your business runs on, TunnelNet Business at $100/month is the same address with a written one-business-day support commitment, onboarding done with a person who verifies the egress address from outside our network before you put it in a policy, and our measured availability published with every incident listed.

And the thing to weigh before you make us load-bearing for payments: we have no uptime SLA and will not offer one until we have six months of measured operating history — 21 February 2027 at the earliest. Our measured availability is on the uptime page and the record is short — we publish the window alongside the number for exactly this reason. If you apply an IP policy naming our address, our availability becomes part of your payment path. Read that page before you decide.