IXOPAY asks for authorized IP addresses when you generate an API key. Route Transaction and Provisioning API traffic through two fixed static EU IPs, enter the pair once at key creation, and every call from your stack arrives trusted.
# one variable pins egress for every IXOPAY call
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
# Transaction API: Basic Auth, API key in the path
curl -s "https://gateway.ixopay.com/api/v3/transaction/$API_KEY/register" \
-u "$API_USER:$API_PASSWORD"
IXOPAY builds the authorized-IP list into API key creation itself: you specify the addresses the key may be used from, comma-separated, or a whole CIDR subnet if you prefer. The policy is simple to state and awkward to live with the moment your egress address refuses to hold still.
The documented flow runs System Setup, API Keys, + New API Key, then a field asking which IP addresses are authorized to use the new key. Generate that key from a rotating cloud egress and you either pin an address you do not control or watch the first integration call arrive from somewhere the key has never heard of.
Multiple addresses are entered comma-separated with no whitespace, the manual's own example being 198.51.100.101,203.0.113.103, and CIDR subnets such as 10.0.0.0/28 are equally welcome. A one-line field is only tidy while the addresses in it stay true; drift turns it into an edit queue you stand in after every infrastructure change.
IXOPAY shows the API key password exactly once, at creation, and it can only be reset afterwards. That makes key churn genuinely expensive: regenerate a key and you re-enter the authorized addresses, re-distribute fresh credentials, and re-test every integration that depended on the old ones.
When a connector enables request signing, each Transaction API request carries Basic Auth plus an X-Signature, an HMAC-SHA512 over the method, body hash, content type, date, and request URI. A call with that many exactly-specified parts deserves an origin address that never moves; an egress that rotates adds one more thing to a request that already has several.
Your Payment Stack
checkout · scheduler · cron jobs
HTTPS Proxy
(Static EU IP)
IXOPAY API
gateway.ixopay.com
On the IXOPAY side, every request your systems make arrives from the same two EU addresses, whether it left a checkout pod, a scheduler run, or a batch job. Both sit in the key's authorized list, so a proxy node failing over changes nothing the gateway can see.
HTTPS_PROXY once in your environment and every operation family, debits, preauthorizations, captures, refunds, payouts, and registers, leaves through the same pair.X-Signature header stay encrypted past the proxy hop, and the signature still verifies because the bytes it covers never change.The authorized-IP field appears exactly when it should be filled: key generation. Paste both fixed addresses while the key is being born and the question of trusted origins is settled before the first request is ever sent.
The two addresses back each other up inside the list IXOPAY already has. A node dropping out mid-settlement-run is invisible, because the survivor presents the exact trust the orchestrator has always seen.
IXOPAY positions its platform around PCI scope reduction of up to 90 percent, so the pair fits the pitch: two named addresses, one EU network path, nothing that rotates. The same two also clear other PSP whitelists, as our Razorpay and Flutterwave guides show.
Teams whose IXOPAY traffic has to arrive from addresses the key already names, on every call.
Debits, preauthorizations, captures, voids, refunds, payouts, and registers all ride the Transaction API with Basic Auth from your backend. One pair covers the entire operation list, and the checkout path never presents the gateway with a stranger.
Tenants, merchants, merchant users, and connectors are managed through the Provisioning API, an optional platform service. Automating lifecycle work means scheduled, unattended calls, and unattended calls deserve an origin that never needs explaining.
Status calls, callback re-checks, and end-of-day settlement jobs run at hours nobody is watching. When they leave from the same two addresses every night, the only thing that varies in your IXOPAY logs is the transaction itself.
Pods that come and go have no single address to name in a whitelist, which is the exact situation our Kubernetes static IP guide covers. The pair fronts the whole cluster, so scale events stop being whitelist events.
One environment variable routes every IXOPAY call, Transaction and Provisioning alike, out of your fixed EU address pair.
Set the variable wherever payment code runs. IXOPAY requires HTTPS with TLS 1.2 or higher and a JSON content type on Transaction API calls, and the proxy alters none of it.
# .env, task definition, or Kubernetes secret, wherever env config lives
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
# register a payment instrument: POST /transaction/:apiKey/register
curl -s "https://gateway.ixopay.com/api/v3/transaction/$API_KEY/register" \
-u "$API_USER:$API_PASSWORD" \
-H "Content-Type: application/json" \
-d "$REGISTER_PAYLOAD"Plain requests picks up HTTPS_PROXY from the environment on its own. IXOPAY authenticates with Basic Auth, so hand over the API user's credentials and let the library build the Authorization header per RFC 7617.
import os
import requests
# requests reads HTTPS_PROXY from the environment automatically
url = ("https://gateway.ixopay.com/api/v3/transaction/"
+ os.environ["API_KEY"] + "/register")
resp = requests.post(
url,
json=register_payload,
auth=(os.environ["API_USER"], os.environ["API_PASSWORD"]),
)
resp.raise_for_status()
# if your connector enables request signing, X-Signature is an
# HMAC-SHA512 over method, SHA512(body), content type, date and
# request URI; the proxy relays TLS bytes untouched, so a
# signature computed before the hop still verifies after itNode's built-in fetch ignores proxy environment variables, so hand it undici's ProxyAgent explicitly.
import { ProxyAgent } from 'undici';
const url = `https://gateway.ixopay.com/api/v3/transaction/${process.env.API_KEY}/register`;
const auth = 'Basic ' + Buffer.from(
`${process.env.API_USER}:${process.env.API_PASSWORD}`
).toString('base64');
const res = await fetch(url, {
dispatcher: new ProxyAgent(process.env.HTTPS_PROXY),
method: 'POST',
headers: { 'Content-Type': 'application/json', 'Authorization': auth },
body: JSON.stringify(registerPayload),
});The authorized-IP field appears inside key creation, which is precisely when to fill it.
# entering the pair, once:
# System Setup -> API Keys -> + New API Key
# select the Service the key is for
# paste BOTH fixed IPv4 addresses into the authorized-IPs
# field, comma-separated with no whitespace
# (CIDR notation is also accepted)
# + Create
# store the password immediately: it is displayed once,
# and can only be reset afterwards
# the pair outlives daily use: redeploys, scale-outs and
# region moves all present the same two addresses, so the
# authorized-IP field never needs revisitingOne field, filled once, for the life of the integration
Every account gets its own pair of static EU IPv4 addresses. Write both into the key at generation and the trust question closes: new services inherit the pair, infrastructure changes inherit the pair, and a failover between nodes never asks anyone to open System Setup again.
Which traffic is covered? Outbound, Basic-authenticated HTTPS from your servers, containers, and cron jobs to IXOPAY: the Transaction API under gateway.ixopay.com/api/v3, the Provisioning API, and any other IXOPAY endpoint your stack calls. Webhooks run the other direction: IXOPAY POSTs statusChange callbacks to the callbackUrl your request names, and you acknowledge with a 200 and a body of OK, so nothing inbound flows through the proxy.
📖 Complete Documentation: For detailed examples, error handling, and advanced configurations, see the Python guide, the Node.js guide, or all guides.
IXOPAY GmbH runs its platform from Vienna as a joint controller alongside IXOPAY, Inc., and the platform's security posture is front and center: PCI-verified status, 3-D Secure, and PCI scope reduction advertised at up to 90 percent. The egress half of that chain is the part you control.
Orchestrated payment traffic carries customer names, billing details, and transaction metadata, much of it personal data under GDPR. Egress from EU data centres keeps your outbound leg inside Europe, which is the half of the journey a Vienna-based processor expects you to be able to describe.
IXOPAY's pitch is shrinking your PCI scope by up to 90 percent, and a fixed, documented egress pair makes the remaining network story easy to tell an assessor. Credentials ride as Basic Auth headers inside TLS the proxy passes through as ciphertext, never readable at the hop.
Both fixed IPs sit in the authorized list from the moment the key is created, so every service, job, and region you run presents addresses IXOPAY already knows.
Infrastructure changes stop touching IXOPAY at all. Scale, redeploy, and migrate as often as you like; the pair the key was born with never changes.
The two addresses back each other up inside the key's list, so a proxy node stepping out mid-run is invisible to the orchestrator and to your settlement totals.
New pods, workers, and scheduled jobs inherit the same pair automatically. The key you create at launch is still complete at a hundred times the traffic.
Basic Auth headers and signed request bytes travel inside TLS the proxy relays untouched. We see ciphertext, never credentials, and signatures verify exactly as they would without us.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
A single environment variable points every IXOPAY call at two fixed EU addresses the key already names, from the first sandbox debit to the ten-thousandth settlement payout.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Yes. When you generate an API key, IXOPAY asks for the IP addresses authorized to use it: multiple entries comma-separated with no whitespace, and CIDR subnets such as 198.51.100.0/28 are accepted. The User Manual documents this for the services API keys authenticate, including the Provisioning API and the BI Data Source, and the key's password is displayed only once at creation.
Set HTTPS_PROXY once wherever your payment code runs. curl and Python requests honor it automatically, while Node's built-in fetch needs an explicit undici ProxyAgent. TLS passes straight through, so Basic Auth credentials and any X-Signature request-signing header arrive intact.
All of your outbound HTTPS: Transaction API operations at gateway.ixopay.com/api/v3 such as debit, preauthorize, capture, refund, payout, and register, plus Provisioning API calls and every other IXOPAY endpoint you use. One pair, written into the key once, covers the lot.
Tell us what your payment stack runs on, and we will map exactly where the pair plugs in.
Contact Our Founders →