Flutterwave IP Allowlisting for Render and Replit Backends
Flutterwave requires source-IP allowlisting for its transfer API. If your Render or Replit backend needs that API and doesn’t already have suitable fixed outbound addresses, route the relevant client through QuotaGuard and register both subscription IPs with Flutterwave.
This guide covers the Flutterwave v3 transfer integration. Payment collection, transaction verification, account resolution, and incoming webhooks have different roles. Choose the route for the operation you’re using.
Identify the Flutterwave operation
Use the API path to identify the requirement. An application that accepts a customer’s payment can use a different API from one that sends money out of its Flutterwave balance.
| Operation | What the official sources establish |
|---|---|
Transfer creation, POST /v3/transfers |
Flutterwave’s transfer prerequisites require server-IP allowlisting. Its transfer-testing instructions require it too. |
Checkout collection, POST /v3/payments |
The Standard checkout guide describes collecting payments. It doesn’t establish a universal caller-IP allowlisting requirement for this flow. |
Transaction verification, GET /v3/transactions/{id}/verify |
The verification guide explains how to confirm a payment. It doesn’t state a caller-IP allowlisting prerequisite. |
Bank-account resolution, POST /v3/accounts/resolve |
Account resolution checks account details. It’s separate from initiating a transfer; its guide doesn’t state an IP prerequisite. |
| Bill payments and virtual-card issuance | Flutterwave’s security guidance also identifies these operations. Bill-payment documentation explicitly requires server-IP allowlisting. |
An omitted prerequisite isn’t a guarantee that an endpoint is exempt from every account policy. Check the exact API, environment, and Flutterwave response. BVN identity verification is also separate from transaction verification and bank-account resolution. Confirm its applicable account requirements with Flutterwave.
Choose an outbound route
Use an existing native route when it supplies the addresses and scope your Flutterwave integration needs. Adding a proxy to an already suitable fixed-egress path introduces another dependency.
| Route | When it fits |
|---|---|
| Render’s shared regional ranges | Consider this only if Flutterwave confirms that it accepts the complete required ranges. Render says a service can use any address within its associated ranges. Flutterwave’s documented individual-IP entry flow doesn’t establish CIDR support. |
| Render Dedicated IPs | Render’s native option supplies three exclusive IPv4 addresses per regional set on Pro workspaces and higher. Current pricing is $100 per set per month on Pro and Scale, with custom Enterprise pricing. Use it when its scope fits and Flutterwave accepts all three addresses. |
| An agreed Replit Enterprise or customer-cloud egress arrangement | Check your agreement for the addresses, covered deployments, and routing guarantees. A continuously running Reserved VM or an IP used for a custom domain doesn’t by itself establish a fixed outbound address. |
| QuotaGuard | Useful when you need a managed, stable pair for selected clients, lack a suitable native route, or want those clients on Render and Replit to use the same subscription’s outbound identity. |
Render documents additional Dedicated IP limits and exceptions, including an unsupported legacy Oregon configuration. Check your workspace’s eligibility.
For Replit, use a backend deployment that runs your server-side client. Autoscale, Reserved VM, and Scheduled deployments run application code. Static deployments serve frontend files without a backend. Keep Flutterwave secret keys and proxy credentials on the server.
Register the addresses for the selected route
For a QuotaGuard route, copy the connection URL and both IPv4 addresses from the relevant subscription’s dashboard. Allowlist both addresses even when a short egress check shows only one. Addresses are assigned per connection, so repeated calls don’t have to alternate between the pair.
QuotaGuard’s direct-billing Starter, Production, and Business plans use shared static pairs. Direct-billing Enterprise includes dedicated IPs and proxy resources. If your destination policy requires exclusive source addresses, select an appropriate dedicated option.
Flutterwave documents this allowlist setup:
- Open Settings, then Whitelisted IP addresses.
- Select Add IP Address and enter an address.
- Select the IPv4 format for a QuotaGuard address and complete Flutterwave’s OTP confirmation.
- Repeat for the other subscription address.
Use the dashboard IP pair for allowlisting. Keep existing authorized entries while assessing a route change. Confirm the account and environment you’re configuring, along with any separate transfer enablement requirements.
Configure the backend client
Save the authenticated proxy URL as a server-side secret. On Render, use the service’s environment settings. On Replit, open Tools, then Secrets under Setup, and add a secret. Check that the intended runtime receives it. Follow Render’s environment-variable instructions or Replit’s Secrets documentation.
Configure the HTTP client that opens the Flutterwave connection to use that URL. A stored secret alone doesn’t route a request. A separate SDK, background job, or verification client needs its own supported configuration.
Use the existing Render integration guide or Replit integration guide for platform and language setup. For Node.js, ensure that the chosen client supports your proxy: a native fetch dispatcher doesn’t configure an unrelated SDK’s internal client.
| Product | Outbound HTTPS behavior |
|---|---|
| QuotaGuard Static | Tunnels the destination HTTPS session without decrypting its payload. The app-to-proxy hop uses a plaintext proxy connection on port 9293. |
| QuotaGuard Shield | Also preserves destination TLS and encrypts the app-to-proxy hop, using an HTTPS proxy connection on port 9294. |
For a workload that must meet PCI-DSS requirements, use Shield, QuotaGuard’s supported product for regulated data. A proxy doesn’t establish compliance for your application. Select the product before registering its IPs: Static and Shield use different address pools.
Check routing without initiating a transfer
Send a request to https://ip.quotaguard.com through the same configured client. Compare the returned address with the subscription’s dashboard pair. Run the check from each backend environment and worker that needs the route.
An IP-check result establishes the egress used by that client. It doesn’t prove that a different Flutterwave SDK uses the proxy, that Flutterwave has accepted the allowlist, or that a transfer will succeed. Don’t initiate a payment or transfer as a connectivity check.
If a real integration request fails, diagnose the response before changing its route:
| Observation | Next check |
|---|---|
Proxy returns 407 |
Check the proxy credentials and configured connection URL. |
| Egress check returns an unexpected address | Check the client configuration and runtime secret. |
Flutterwave returns 400 |
Read the error message. Transfer documentation lists several causes, including invalid fields and an unallowlisted source. The status alone doesn’t identify the cause. |
Flutterwave returns 401 |
Check its API key and the intended environment. |
Transfer request returns HTTP 200 |
Inspect the transfer’s processing status. An accepted HTTP request isn’t proof of completed delivery. |
Handle incoming webhooks separately
Flutterwave webhooks travel from Flutterwave to your application’s public endpoint. An outbound proxy doesn’t change that connection’s source. Flutterwave’s webhook guide recommends signature verification and warns that its sending IPs can change.
Use transaction verification to confirm payment details before fulfilling an order. That server-side verification call is a separate request from the incoming notification.
For help selecting a supported proxy client, contact QuotaGuard.