Why do payment partners ask for my IP addresses?

Processors, banks and other API providers often restrict which source addresses may call them, or which addresses may receive their webhooks, as a second control behind authentication. Ripple's Payments Direct documentation, for example, tells customers that a trusted IP address that is not allowlisted may lead to payment transaction failures. Your partner's own documentation says which of their endpoints apply to you.

What happens to allowlists if I change CDN or hosting provider?

If the addresses you gave partners were assigned by the old provider, they usually stop being yours when the contract ends. Every partner that allowlisted them has to approve new addresses before traffic moves, and partners vary in how quickly they do that. That lead time is the exit cost to price in.

Does owning an IP block remove the need to allowlist-check partners?

No. Owning address space means the addresses you hand out can stay the same across provider changes. Partners still need to hold the right list, and many say allowlisting should sit behind signature or certificate verification, not replace it.

Is a private Anycast network required for stable partner IPs?

No. A smaller option is a fixed set of egress addresses from a provider that lets you keep or transfer them, or a documented proxy tier with static addresses. Private Anycast is worth considering when you also want the edge itself to be substitutable. Compare the options on exit terms, not on feature lists.

Is this the same question as DORA concentration risk for a bank?

No. The DORA article covers whether a single edge provider is a regulatory dependency. This one is operational: what breaks, and who must act, in the weeks around a provider change for a platform whose partners pin its addresses. See the linked DORA article for the regulatory reasoning.

Private Anycast for a Fintech Payment Platform: Keeping Partner IP Allowlists Valid When the Edge Changes

The short answer

A payment platform's IP addresses are not only a networking detail. Processors, banks and other partners often allowlist them, so the addresses become part of the integration contract. If those addresses are assigned by a CDN or hosting provider, leaving that provider means asking every partner to approve new ones, and the payments that depend on a partner that has not yet done so can fail. If the platform holds its own address space and announces it from its own network, the addresses can stay the same when the provider underneath changes. That is the practical argument for a private Anycast network on a payment platform, and it is separate from cost or regulation.

Who this is for

This is for a CTO or head of infrastructure at a payment gateway, PSP or embedded-finance platform that gives partners a list of source or destination addresses, and is either renewing an edge or hosting contract or asking what leaving would cost. It is not for platforms whose partners authenticate purely with signed requests and publish no allowlist requirement. If your concern is regulatory substitutability for a bank, read Private Anycast for a digital bank and DORA concentration risk. For the general account-ban and cost case, read building a private Anycast edge from scratch.

Where allowlists sit in a payment integration

Allowlisting runs in two directions, and the two fail differently.

Direction	Who holds the list	What breaks if addresses change
Your calls out to a partner (processor, bank API)	The partner	Partner rejects your requests until it adds the new source addresses
Partner calls into you (webhooks, callbacks)	You, on your firewall or edge	You drop real callbacks if the partner's published addresses change and you did not update
Partner pins your inbound endpoint	The partner, on their side	Partner's connection to a changed address fails or is blocked

Vendor documentation shows the pattern. Ripple states that a trusted IP address that is not allowlisted may lead to payment transaction failures, and suggests routing through proxy servers with static addresses to avoid maintaining large lists. GoCardless does not support IP allowlisting for API traffic, treats it as valid for inbound webhooks, and says it gives at least two weeks' notice before changes. Payt's documentation says its addresses may change and recommends hostnames where possible. Practice varies by partner, which is why your own list of partners matters more than any general rule.

What changes when the addresses are yours

Allowlists key on addresses. Whoever holds the address space decides whether they survive a provider change.

Situation	Addresses	Partner action on provider change
Addresses assigned by CDN or host	Belong to the provider	Every partner approves a new set before cutover
Addresses held by you with a registry record in your name, announced by a provider on your behalf	Stay yours	Often none, if the new provider can announce the same block; confirm with the new provider
Own ASN and address space, announced from your own points of presence	Stay yours	None for address reasons; you run the routing

The middle row is a real option and cheaper than a network build. The question to ask any provider is the one in who holds the ASN, the IP blocks and the exit terms: whose name is on the registry record, and what is the process to move it.

When private Anycast is the answer, and when it is not

Choose private Anycast when several of these are true: many partners pin your addresses, partner change lead time is long or unknown, you want more than one upstream provider without renumbering, and your own team can operate BGP or will buy the operation. Do not choose it just to keep addresses stable if a provider that lets you hold your own block would do. A network you cannot operate trades a partner-update problem for a routing-outage problem; the BGP self-withdrawal outage article shows how that failure looks.

If you do move traffic onto an owned edge, do it in phases, with partner allowlists updated ahead of cutover and the old addresses left live until each partner confirms. The mechanics are in the live cutover runbook; they apply to any industry.

What to inventory before talking to anyone

Every partner that allowlists your addresses, in each direction, and where the list is documented.
For each partner: who approves a change, how it is requested, and how long it has taken before. Use your own records; do not assume a time.
Which of your addresses are assigned by a provider and which are held by you.
The contract exit terms for each provider that holds addresses you gave out.
Which integrations also verify signatures or certificates, so an allowlist is a second control and not the only one.

Limitations

This article does not claim a particular partner's allowlist process or notice period; read each partner's documentation and your agreement. Owning address space does not remove the need for transit providers, and it does not make partners update their lists for you. It is not a PCI DSS or DORA opinion. The vendor documents above describe those vendors only.

Decision and next step

If a provider change would mean writing to a long list of partners and waiting, the addresses are a hidden part of your exit cost. Decide whether holding your own block, or a full private network, is worth that. Request a network design review and we will scope what your partner list needs against what you can operate.

Sources and review

Vendor behaviour is taken from the public documentation of Ripple Payments Direct, GoCardless and Payt, read 2026-10-20; check the current versions. No AnySec-original statistics are used. Author: AnySec Engineering. Published 2026-10-20; last reviewed 2026-10-20.

If you want an honest read on whether stable partner addresses justify a network build, get a fixed quote. We will say so if a provider that lets you hold your block is enough.