Automating payments or PSD2 flows with Bunq from containers or serverless? Every redeploy shifts the IP, breaking API-key trust and PSD2 audit trails. Route your Bunq calls through two fixed static EU IPs.
import requests
# leaves through static EU IP
# HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
r = requests.post(
"https://api.bunq.com/v1/user/.../monetary-account/.../payment",
headers={"X-Bunq-Client-Authentication": "TOKEN"},
json={"amount": {"value": "10.00",
"currency": "EUR"}}
)
Bunq is a Dutch bank with PSD2 obligations, so where your payment calls come from is part of the compliance story. Rotating egress makes that hard to tell.
Teams restrict their Bunq API key to specific IPs. When a pod or function moves to a new address, requests to api.bunq.com come back unauthorized, and payment and PSD2 calls silently stop working.
Cloud functions and Kubernetes assign a fresh outbound IP on each deploy and autoscale. A scheduled payment that worked at noon can fail at midnight with no code change, because the source IP shifted underneath it.
Processing payment data under PSD2 means strong customer authentication and traceable access. Auditors want a documented, stable egress for banking calls, not an address list that changes every release.
The Bunq API exposes over 300 operations across payments, accounts, cards, and PSD2 flows. Each call from each environment rides a different rotating IP, so there is no single, predictable address to whitelist or audit.
"Which IP addresses do our Bunq API calls come from?"
You want one fixed answer, not "it depends which pod served the payment."
Your banking app
HTTPS Proxy
(Static EU IP)
Bunq API
Bunq sees your calls from the same pair of EU addresses every time, whether it's a payment, a PSD2 authorisation, or an account query. Two IPs back the account, and if one is down the other takes over.
api.bunq.com, with no SDK rewrite.
requests, fetch, and anything that honours the standard proxy environment variables.
Automating payments, transfers, or account management through the Bunq API who need their key to keep working through every deploy.
Building PSD2-compliant integrations that connect to Bunq user accounts and need traceable, EU-resident outbound access.
Shipping EU products that use Bunq for payments and need IP-whitelisted, GDPR-aligned access across dev and prod.
Accountable for where payment data and PSD2 flows are sent, who want a documented EU egress rather than a moving address.
Set HTTPS_PROXY and your Bunq calls leave through your fixed EU IP. No rewrite to your payment code.
Drop HTTPS_PROXY into your environment and requests honours it automatically. The payment call below already leaves through your static IP.
# .env or shell
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
BUNQ_SESSION_TOKEN=your_session_token
import os
import requests
# requests reads HTTPS_PROXY from the environment automatically
resp = requests.post(
"https://api.bunq.com/v1/user/123/monetary-account/456/payment",
headers={"X-Bunq-Client-Authentication": os.environ["BUNQ_SESSION_TOKEN"]},
json={
"amount": {"value": "10.00", "currency": "EUR"},
"description": "Invoice #1234",
"counterparty_alias": {"type": "IBAN", "value": "NL.."},
},
)
print(resp.json()["Response"][0]["id"])
Node's fetch doesn't read the env var on its own, so pass the proxy explicitly with https-proxy-agent.
// .env or shell
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
BUNQ_SESSION_TOKEN=your_session_token
const { HttpsProxyAgent } = require('https-proxy-agent');
const agent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
// This POST leaves through your static EU IP
const res = await fetch('https://api.bunq.com/v1/user/123/monetary-account/456/payment', {
method: 'POST',
headers: {
'X-Bunq-Client-Authentication': process.env.BUNQ_SESSION_TOKEN,
'Content-Type': 'application/json',
},
body: JSON.stringify({
amount: { value: '10.00', currency: 'EUR' },
description: 'Invoice #1234',
}),
agent,
});
console.log(await res.json());Set the variable in your platform config, the same approach in every environment. Never paste the proxy string in plaintext.
# Docker Compose: load a .env file
services:
app:
env_file:
- .env
# Kubernetes: pull it from a Secret
env:
- name: HTTPS_PROXY
valueFrom:
secretKeyRef:
name: outboundgateway-proxy
key: proxy-url
# AWS Lambda: function environment variables
HTTPS_PROXY=${OUTBOUNDGATEWAY_PROXY_URL}Two IPs, so a payment doesn't depend on one box
Your account comes with two static IP addresses (for example 51.xx.xx.10 and 51.xx.xx.11). Register both against your Bunq API key. If one proxy node is briefly unavailable, traffic shifts to the other, so an overnight redeploy isn't the thing that breaks a scheduled payment.
📖 Want the longer version? Worked examples, error handling, and other languages are in the Python SSL Proxy Guide, Node.js Guide, and the rest of the docs.
Bunq is a Dutch bank with PSD2 obligations, so the outbound path should stay in Europe.
The proxy runs in EU data centres, so your Bunq API traffic stays within European borders rather than wherever a container happens to be scheduled.
Processing payment data is regulated under PSD2 and GDPR. A stable, documented EU egress is the kind of detail a payment-compliance review asks for.
Traffic doesn't bounce through US infrastructure on its way to Bunq, which keeps payment data inside the EU and removes a wrinkle from PSD2 data-transfer reviews.
When a reviewer asks where your Bunq calls originate from, the answer is two fixed EU addresses, not a list that changes every release. The failover pair covers maintenance windows.
Two addresses to register against your key, with automatic failover, so your traffic isn't riding on a single point of failure.
Add one env var and your existing requests, fetch, or Bunq SDK code starts routing through the proxy.
European data centres and a GDPR-conscious setup. Bunq is Dutch, so your traffic stays in the EU, end to end.
Payments, accounts, cards, PSD2 authorisation, webhooks all go out through the same stable pair of IPs.
TLS passthrough means the proxy can't read your traffic. Payment data, auth tokens, and your API key stay private the whole way.
Starting from €29/month. Flexible plans for every scale. Cancel anytime.
Stop letting pod restarts and autoscaling decide which IP your payments come from. Put Bunq behind one stable, PSD2-conscious EU address.
€29/month starter plan • 7-day refund policy • Direct founder support
Yes. The Bunq SDK and standard HTTP clients use HTTP under the hood, so setting HTTPS_PROXY applies to their calls whether you authenticate with an API key or an OAuth session token. You can also call api.bunq.com directly with requests or fetch and get the same effect.
That's the main reason teams add the proxy. Bunq keys can be tied to specific source IPs, but containers and functions get a new address on every deploy, which would normally break that restriction. By routing outbound calls through a fixed pair of EU addresses and registering both against the key, the key keeps authorising requests no matter how often your deployment restarts.
Yes. The proxy isn't endpoint-specific. Any call your app sends to api.bunq.com, whether it's a payment, a PSD2 registration, an account query, or a card operation, leaves through the same fixed pair of EU IPs. One whitelist covers the whole API surface.
Happy to talk through how a two-IP egress fits your specific Bunq setup, whether it's payments, PSD2, or account automation.
Contact Our Founders →