Static IPs for Fintech APIs: Mercury, Modern Treasury, Adyen, Stripe, and Unit

If you're building a fintech app that touches more than one financial API, the IP allowlist requirement keeps showing up. Mercury, Modern Treasury, Adyen, Stripe, and Unit each enforce customer-side IP allowlisting on credentials that can move money or write account data. The fix is the same across all of them: route outbound API calls through a static IP proxy, register the two IPs once per vendor, and stop chasing dynamic cloud IPs across deploys.

The Common Pattern: One Proxy URL, Two Static IPs, Five Allowlist Updates

The five vendors covered here vary in dashboard UI and credential model, but the underlying allowlist mechanism is the same. Each vendor's API rejects requests that originate from IP addresses not registered on the relevant credential. The QuotaGuard side is identical for all of them.

Sign up at QuotaGuard, set the QUOTAGUARDSTATIC_URL environment variable on your application, configure your HTTP client to route outbound calls through that proxy, and add the two static IPs from your QuotaGuard dashboard to each vendor's allowlist. The proxy URL format is the same across vendors:

QUOTAGUARDSTATIC_URL=http://username:password@us-east-static-01.quotaguard.com:9293

Setup takes 2 minutes per vendor for the allowlist update. The QuotaGuard configuration is one-time. Static IPs stay stable across application deploys, plan changes, and infrastructure migrations, so the allowlists you register on each vendor's dashboard remain valid indefinitely.

For banking and payment integrations subject to PCI-DSS, SOC 2, or HIPAA compliance, QuotaGuard Shield ($29/month starter) uses SSL passthrough so QuotaGuard never decrypts the traffic in transit. The setup pattern is identical, just with Shield's proxy URL instead of Static's.

Per-Vendor Allowlist Mechanisms

Mercury Bank

Mercury requires IP allowlisting for Read and Write tokens and for Custom tokens with write scopes. From Mercury's API Token Security Policies: "To further secure your token, we require you to whitelist IP addresses or ranges from which you expect to use your Read and Write token."

The allowlist supports both individual IPv4/IPv6 addresses and CIDR ranges. Mercury's docs explicitly recommend QuotaGuard for the Heroku case: "For Heroku, you can use the Fixie or QuotaGuard Add-Ons." Read Only tokens don't require allowlisting. The full QuotaGuard + Mercury integration walkthrough lives at the dedicated Mercury post.

Modern Treasury

Modern Treasury allowlists IPs per API key. From the official docs: "For each API Key, you can optionally specify which IP addresses are allowed to make requests. Modern Treasury will reject any IP addresses that are not included in the allow list."

The setting lives in the Developers > API Keys section of the dashboard. When creating or editing an API key, an "Allowed IPs" section accepts one or more IP addresses. Changes apply immediately. Modern Treasury's permissioned API keys also let you scope individual keys to specific bank accounts or read-only access, giving you defense in depth alongside the IP allowlist.

Adyen

Adyen allowlists IP ranges at the API credential level. From Adyen's API credentials documentation: "As a security measure, you can add allowed IP addresses to your API credential. When you add an allowed IP range, only requests originating from that range will be permitted."

The setting lives in Customer Area > Developers > API credentials > Server settings > Allowed IP range. The Management API also exposes this via the apiCredentials endpoint, so allowlist updates can be automated. Adyen's docs note the default behavior: "If the list is empty, we allow requests from any IP. If the list is not empty and we get a request from an IP which is not on the list, you get a security error."

Stripe

Stripe supports IP restrictions on secret and restricted API keys. From Stripe's keys best practices: "You can increase the security of a secret or restricted key by limiting the IP addresses that can use it to send API requests."

Stripe explicitly recommends this for services with stable egress IPs: "We recommended this if your service has stable egress IP ranges and a change management process for updating the allowlist when those egress ranges change." The restriction lives in the Stripe Dashboard's API keys section, applied per individual key. Stripe's restricted keys also let you scope permissions to specific resources (e.g., read-only dispute access for a third party), so IP restriction stacks with permission scoping for layered defense.

Unit

Unit allowlists IPs on Org API tokens. From Unit's Org API tokens documentation, IP allowlisting is an optional attribute on token creation: "A comma separated list of IP addresses that are allowed to use the Org API token."

The allowlist applies to the broad, system-level Org API tokens used for production backend integrations. Customer Tokens (which are end-customer specific and scoped to a single customer's resources) have their own security model that includes built-in 2FA and short expiry. For the typical backend-to-Unit pattern where your application calls Unit on behalf of many end customers, the Org API token plus IP allowlist is the relevant control.

Vendors That Don't Require Static IPs

Not every fintech API uses IP allowlisting. If you're integrating with one of these, you don't need QuotaGuard for that specific integration. The pattern matters because plenty of teams over-engineer outbound IP routing for vendors that secure their APIs differently.

Plaid uses OAuth-based authentication, client_id/secret pairs, and optional mutual TLS for data partner integrations. Plaid does not enforce customer-side IP allowlisting on outbound API calls. Plaid's docs that mention IP allowlisting refer to allowlisting Plaid's IPs on your firewall for inbound traffic (webhooks, scheduled updates from Plaid to your servers). That's the opposite direction from outbound static IP need.

Wise protects sensitive endpoints with Strong Customer Authentication (SCA) using RSA key pairs rather than IP allowlists. Generate a public/private key pair, register the public key with Wise, and sign sensitive requests with the private key. No IP restriction in the standard security model.

Increase uses bearer token authentication for its REST API. Their public documentation doesn't surface a customer-side IP allowlist feature. If you're on an enterprise contract with Increase, this might be available through your account contacts, but it's not a self-serve dashboard feature.

If you're integrating with Plaid, Wise, or Increase and also integrating with Mercury, Modern Treasury, Adyen, Stripe, or Unit, you still need static IPs for the second group. The first group just doesn't add to your allowlist maintenance burden.

QuotaGuard Tip: Allowlist Both IPs, Not Just One

QuotaGuard provides two static IPs per account behind a load balancer. Either IP can serve any given request, and the system automatically routes around the unhealthy one if either becomes unavailable. If you only register one of your two QuotaGuard IPs in a vendor's allowlist, roughly half your requests will fail when the load balancer routes through the unregistered IP.

Every vendor in this post accepts multiple entries on a single token's allowlist. Add both IPs to each vendor's allowlist on the initial setup. You won't need to update either side again unless you change QuotaGuard regions or upgrade to a dedicated IP plan.

Frequently Asked Questions

If I'm integrating with all five vendors, do I need five QuotaGuard accounts?

No. One QuotaGuard account gives you one pair of static IPs that all five vendors will allowlist. Register the same two IPs on each vendor's dashboard. Bandwidth is bundled on every plan, so calls to multiple vendors don't multiply your costs.

Do I need QuotaGuard Static or QuotaGuard Shield for fintech APIs?

For most fintech integrations, Shield is the safer default. Banking data, payment card data, and transaction records all fall under at least one of PCI-DSS, SOC 2, or your own internal data-handling policies. Shield uses SSL passthrough so QuotaGuard never decrypts the traffic in transit, which simplifies compliance audits and removes QuotaGuard from the data flow. Shield Starter is $29/month versus Static Starter at $19/month. For non-regulated fintech use cases (e.g., a personal finance tool that only fetches your own balance), Static is sufficient.

What happens if I rotate an API key on one of these vendors?

The IP allowlist is attached to the credential. When you create a new credential or rotate a key, you re-register the IP allowlist on the new credential. Your QuotaGuard IPs stay the same, so the values you register are identical to before. Most teams handle this with a runbook or automated provisioning script that creates the credential, sets the allowlist, and stores the new secret.

How do I handle multiple environments (sandbox, staging, production)?

Each environment typically has its own API credential, and each credential has its own allowlist. Add your QuotaGuard IPs to each environment's credential separately. If you use different QuotaGuard accounts per environment (some teams do this for blast radius separation), each environment's allowlist gets that environment's specific IPs.

Can I use CIDR ranges instead of individual IPs?

Most of these vendors accept CIDR notation. Mercury supports both individual IPs and CIDR ranges. Modern Treasury accepts CIDR. Adyen's "Allowed IP range" field accepts CIDR notation. Stripe accepts individual IPs (the docs don't explicitly mention CIDR for key restrictions, so check current behavior on rotation). Unit's allowlist is documented as a comma-separated list of IP addresses.

For QuotaGuard's two-IP setup, CIDR doesn't add value: you have exactly two specific IPs to register. CIDR matters when you're trying to allowlist a broader range, which is what you'd want to avoid on a security-sensitive allowlist anyway.

What if my vendor has both webhook (inbound) and API (outbound) traffic?

The QuotaGuard pattern in this post solves the outbound direction: your app calls the vendor's API from a static IP. Webhooks flow the opposite way: the vendor sends events to your endpoint. Your inbound webhook endpoint just needs to be publicly reachable. The vendor doesn't care about your outbound IP for webhook delivery to your endpoint.

If you also need a static inbound endpoint (some compliance scenarios require this), QuotaGuard Static includes inbound proxy capabilities on all direct plans starting at $19/month. Contact QuotaGuard support after signup to enable inbound proxy provisioning.

Why doesn't Plaid need IP allowlisting if it's a fintech API?

Plaid's security model uses different controls. Authentication is per-request via client_id and secret, sensitive endpoints can require mutual TLS where Plaid validates a certificate you've registered with them, and many endpoints use OAuth-style token flows scoped to individual end users. The combination provides equivalent security to IP allowlisting without requiring customers to maintain static egress IPs. Different model, same goal.

Does this also cover crypto exchanges, broker APIs, and other regulated APIs?

The same pattern works for crypto exchanges (Binance, Coinbase, Kraken, OKX), broker APIs (Interactive Brokers, Zerodha Kite Connect, Upstox, Dhan), and any other API that uses customer-side IP allowlisting. QuotaGuard has dedicated posts for many of these. The fintech vendors in this post are specifically the banking-as-a-service and payment processing category. Crypto and broker APIs have their own roundup at the crypto trading bot post.

Five Allowlists, One Static IP Setup

Mercury, Modern Treasury, Adyen, Stripe, and Unit all enforce IP allowlisting on the API credentials that matter most. Plaid, Wise, and Increase use different security controls. For teams integrating multiple fintech APIs, the IP allowlist requirement compounds: every dynamic cloud IP change breaks five different integrations at once.

QuotaGuard solves this in 2 minutes of configuration. One proxy URL, two static IPs, and a five-minute trip through each vendor's dashboard to register the allowlist. The IPs stay stable across application redeploys, plan changes, and infrastructure migrations.

QuotaGuard Static starts at $19/month, Shield at $29/month (recommended for regulated banking and payment data). 3-day trial, credit card required. See pricing or contact us with setup questions.