Fintecture payment flows chain OAuth tokens, signed requests, and webhook reactions end to end. Route the outbound half through two fixed static EU IPs and the whole lifecycle speaks from one address.
import requests, os
# HTTPS_PROXY from env is picked up
tok = requests.post(
"https://api.fintecture.com/pis/token",
auth=(os.environ["FIN_APP_ID"],
os.environ["FIN_APP_SECRET"])).json()
Initiating a Fintecture transfer touches your backend repeatedly over minutes or hours. Each of those touches is an outbound request, and each one has to look like it came from the same trustworthy place.
One payment means a token request to the PIS endpoint, a signed initiation, status checks while the bank decides, and a reaction when the webhook lands. Spread across serverless handlers or scaling pods, those steps can each fire from a different address, and the trail you show an auditor fragments accordingly.
Sandbox traffic goes to api.sandbox.fintecture.com and live traffic to api.fintecture.com, each with its own keys. Keep both environments behaving identically at the network layer and promotion day holds no surprises about where requests originate.
You are integrating with a licensed French payment institution, so security questionnaires, penetration tests, and internal reviews come with the territory. "What address initiates your transfers?" deserves a two-line answer, not an investigation into whichever NAT your cluster happened to use.
Fintecture verifies webhook delivery with the Fin-Api-Signature header and your signed requests carry your private key's proof. That authenticates the messages. It does nothing about where your token requests and initiation calls physically originate, which is the gap a fixed egress closes.
Your backend
tokens, signing, polls
HTTPS Proxy
(Static EU IP)
api.fintecture.com
tokens, initiation, status
Fetch the token, sign the initiation, poll the status: Fintecture's gateway logs one consistent European source for all of it, and your payment trail reads like a single well-behaved client.
requests and friends honour HTTPS_PROXY without a single change to your Fintecture integration code.Run by an EU company for workloads where the source address is part of the security story: payment initiation, account data, and the audits that follow both. The two addresses come as a failover pair, so a payment in flight rides out proxy maintenance without changing origin.
The proxy rides in an environment variable. Your existing Fintecture SDK calls, HTTP signatures, and webhook handler stay byte for byte identical.
A French payment institution on one side and European data centres on the other keeps the whole data path inside the regulatory frame you already operate in.
Teams moving real money through Fintecture, from first sandbox call to daily settlement volumes.
Invoicing platforms using Immediate Transfer or Request To Pay to settle customer bills, where every payment attempt must trace back to a known origin.
Reconciliation and treasury tools pulling Account Information data on schedules, needing their polling jobs to come from an address their own firewall recognises.
Shops running Fintecture's CMS plugins or a custom checkout that promote from sandbox to production and want both environments egressing identically.
Licensed or licensing fintechs building on a fellow payment institution, whose compliance files need a simple statement about where outbound traffic originates.
Set the variable before your code runs, and every request to api.fintecture.com follows the fixed pair.
Fetch a PIS access token with your application credentials, then initiate the payment. Both calls leave through the static EU pair because requests reads HTTPS_PROXY from the environment on its own.
import requests, os
# HTTPS_PROXY is honoured automatically
token = requests.post(
"https://api.fintecture.com/pis/token",
auth=(os.environ["FIN_APP_ID"],
os.environ["FIN_APP_SECRET"]),
timeout=30,
).json()
payment = requests.post(
"https://api.fintecture.com/pis/initiate",
headers={"Authorization": f"Bearer {token['access_token']}"},
json=payload, timeout=30,
)Node's fetch ignores proxy variables, so hand it an explicit dispatcher. Build it once and share it across your token refreshes and payment calls.
import { ProxyAgent } from "undici";
const dispatcher = new ProxyAgent(
process.env.HTTPS_PROXY);
const res = await fetch(
"https://api.fintecture.com/pis/initiate",
{ method: "POST", dispatcher,
headers: { Authorization: `Bearer ${token}` } });Keep the proxy setting and your Fintecture credentials together in a file that never enters the image or the repository.
# .env.fintecture (git-ignored)
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
FIN_APP_ID=your-app-id
FIN_APP_SECRET=your-secretservices:
payments:
image: your-payments-service
env_file: .env.fintectureWrite both addresses into your security file
Your account includes two fixed European addresses configured as a redundant pair. Declare them in the answer to "where do your Fintecture calls originate": whichever node is active, the source your counterparty records stays on that two-line list.
📖 Complete Documentation: For detailed examples, error handling, and advanced configurations, see the all guides.
Payment initiation and account data live under PSD2 and GDPR. A predictable European egress makes the network side of that story easy to document.
Fintecture operates as a licensed payment institution under PSD2. Routing your side of the conversation through EU nodes keeps the whole chain inside the same regulatory perimeter.
Access tokens, signed request bodies, and account data remain encrypted between your backend and Fintecture. The gateway relays ciphertext and nothing else.
Tokens, initiations, and polls all reported from the same two European addresses, so logs on both sides line up.
A single environment variable steers your existing integration. No SDK forks, no changed signatures, no new failure modes in code review.
The second node takes over mid-payment without a blip, and because both addresses are permanent, failover never introduces an unfamiliar source.
Exits inside the Union for a PSD2 workflow, which simplifies the network description in your GDPR records.
Point sandbox and production at the same pair and promotion changes credentials only, never the network path.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
One environment variable and every Fintecture call you make, from sandbox token to production transfer, leaves through the same two fixed EU IPs.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
No. Webhooks travel from Fintecture's servers to your endpoint, and Fintecture verifies delivery through the Fin-Api-Signature header with signature checks as the source of truth. Their published IP allowlists are for filtering inbound traffic on your firewall. The proxy addresses the other direction: the token requests, signed initiations, and status polls your backend sends out.
It cannot. Your HTTP signatures are computed over the request content by your code before the TLS session is established, and the proxy relays that encrypted session without decrypting or modifying it. Fintecture receives the signed request exactly as your backend produced it, now from a stable European address.
Yes. Point both api.sandbox.fintecture.com and api.fintecture.com traffic at the same static pair. The credentials differ per environment by design, but the network path stays identical, so behaviour you verified in sandbox holds the day you switch base URLs.
Tell us about your payment flow and how your security review framed the egress question. We speak fluent open banking.
Contact Our Founders →