TrueLayer is the secure pipe between your app and your users' banks, and integrations like that get audited. Send every truelayer.com payment and data call out through two static EU IPs your security review can sign off on.
# picked up by requests automatically
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
requests.post('https://api.truelayer.com/v3/payments',
headers={'Authorization': f'Bearer {token}'},
json=payment_payload)
TrueLayer never sees your users' bank credentials, which is exactly why everyone downstream asks hard questions about the traffic your side of the pipe sends.
Before a bank, partner, or enterprise customer connects to your product, their questionnaire asks which address ranges your systems call from. Answering "wherever the platform decides" ends the conversation badly.
TrueLayer's own security best practices tell you to implement IP whitelisting where possible. Serverless and container platforms hand your backend a different egress on every deploy, so the address you registered yesterday is stale today.
You create the payment at /v3/payments, poll its status while the user authorizes in their banking app, and reconcile from the webhook handler. Those steps often run in different services and environments, each with its own exit address, and inconsistency is what monitoring and audits notice first.
Test traffic heads to api.truelayer-sandbox.com while live payments go to api.truelayer.com. Keeping the two straight in firewall rules, alerting, and audit logs gets simpler when both leave through one address pair you control.
Your backend
payment + data services
HTTPS Proxy
(Static EU IP)
api.truelayer.com
payments + data API
Payment creation, status polling, token refresh, data pulls: whatever leaves your infrastructure toward TrueLayer carries the same two European addresses. One is the spare tire for the other, so the pair you registered is always the pair in use.
HTTPS_PROXY once per environment and Python services inherit it; Node services pass a single dispatcher.A concrete pair of addresses to write into the security review, replacing a paragraph about how cloud egress works.
Python picks the proxy up from the environment, Node attaches it as a dispatcher, containers get it as an env file. Same two IPs everywhere.
Traffic to a PSD2 platform leaves from EU data centres, which keeps the residency description in your documentation short and true.
Teams building on TrueLayer who need their side of the connection to look as disciplined as the platform they are calling.
Products initiating open banking payments where the bank or acquirer onboarding call includes a field for your outbound address ranges.
Account aggregation, KYC-style verification, and Signup+ flows that pull sensitive financial data on a schedule from every environment you operate.
PSD2-adjacent operations whose penetration tests and compliance audits expect controlled, documented egress for every third-party financial API.
SaaS running staging, sandbox, and production side by side, where one address pair collapses three sets of firewall exceptions into one.
Point your existing HTTP stack at the proxy and every request to api.truelayer.com changes origin.
The requests library reads HTTPS_PROXY from the environment on its own. Export the variable where your payment service starts and this code already routes through your fixed IP.
import os
import requests
resp = requests.post(
"https://api.truelayer.com/v3/payments",
headers={"Authorization": f"Bearer {os.environ['TL_TOKEN']}"},
json={
"currency": "EUR",
"payment_method": {
"type": "bank_transfer",
"provider_filter": {"countries": ["DE"]},
},
"amount_in_minor": 2500,
},
timeout=30,
)
# HTTPS_PROXY from the environment is applied automatically
With undici, attach the proxy as a dispatcher and every fetch in the service uses it.
import { fetch, ProxyAgent } from "undici";
const dispatcher = new ProxyAgent(process.env.HTTPS_PROXY);
const res = await fetch("https://api.truelayer.com/v3/payments", {
method: "POST",
headers: { Authorization: `Bearer ${process.env.TL_TOKEN}` },
body: JSON.stringify(payment),
dispatcher,
});
Keep credentials out of the file; load them from the environment or your secret store.
# docker-compose.yml
services:
payments-api:
build: .
env_file: .env # HTTPS_PROXY=..., TL_TOKEN=...
# Kubernetes
env:
- name: HTTPS_PROXY
valueFrom:
secretKeyRef:
name: outboundgateway
key: proxy-url
Write both addresses into the review
Each account carries two static European addresses and the second exists to take over without ceremony. Name the pair in your security questionnaire and your firewall rules: whichever node is serving, the source your partners observe never leaves that list.
📖 Complete Documentation: For detailed examples, error handling, and advanced configurations, see the all guides.
Open banking traffic carries account details and payment instructions. Regulators and counterparties care about where that traffic travels.
Requests carrying personal financial information leave through European data centres, which keeps your processing records straightforward.
The proxy forwards sealed traffic to TrueLayer without terminating it, so tokens, consent references, and payment payloads stay private end to end.
Two European IPs, one standing behind the other, so the pair in your paperwork is always the pair in use.
One env var for Python, one dispatcher for Node, one env file for containers. No SDK fork, no wrapper library.
Sealed TLS passes through untouched; the proxy can read neither token nor payload.
Egress inside the Union for a platform operating under Europe's PSD2 regime.
Staging, sandbox, and production all report the same source, which makes alerts and audit logs legible.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Fill the source-address field of your next security questionnaire in one line: two static EU IPs, failover included, every TrueLayer call behind them.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Not as a documented per-credential restriction. The reason teams still pin their egress is the opposite direction: TrueLayer's security best practices recommend implementing IP whitelisting, and your own reviewers, banking partners, and auditors expect a controlled, declared source range. A fixed address pair satisfies that expectation regardless of which side enforces it.
Yes. Requests to api.truelayer-sandbox.com and api.truelayer.com are both ordinary outbound HTTPS, so the same proxy setting covers test and live traffic. Keeping them behind one address pair also means your logs and firewall rules treat the two hosts consistently.
Webhooks from TrueLayer arrive inbound at your public endpoint and do not traverse the proxy; what the proxy governs is everything you send out, including creating payments, polling status, refreshing tokens, and pulling account data. Restricting your webhook endpoint to known TrueLayer source ranges is a separate, complementary step on their documentation.
Happy to talk through your TrueLayer setup, your environments, and how a fixed EU pair reads in your security documentation.
Contact Our Founders →