Corefy attaches an IP whitelist to every API key you generate. Route Merchant API traffic through two fixed static EU IPs, add the pair once to each key, and payment requests from your entire stack arrive from addresses Corefy already trusts.
# one variable pins egress behind the key whitelist
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
# the Merchant API authenticates with X-AUTH-KEY;
# TLS passes through, so the key stays sealed
curl -s "https://processing.eu.corefy.com/api/v1/payment-requests" \
-H "X-AUTH-KEY: $COREFY_API_KEY" \
-H "Content-Type: application/json" \
-d @payment-request.json
Corefy puts the IP whitelist inside each API key, locks the key's permissions at creation, and shows the key value exactly once. That design rewards teams whose source addresses never move and quietly taxes everyone else.
The whitelist is not an account-level setting. It lives in the Additional settings of each API key, under the Developers tab of the merchant account it belongs to. Run several merchant accounts or keys, as orchestration platforms usually do, and a drifting egress address means hunting down and re-editing the same lists across all of them.
When you create a key, you pick its scope presets or a custom grid of read-only, write, and full access rights. Corefy states it plainly: those permissions can be established only during creation, with no modification afterwards. So regenerating a key to escape a stale whitelist means re-selecting every permission, re-distributing a new secret, and re-testing every integration that used the old one.
Corefy shows the key value only in the creation modal, viewable and copyable a single time. Teams respond rationally: keys live for months or years. That long life makes the editable IP whitelist the one security dial left to turn, and an egress address that keeps changing turns it for you on every deploy.
Corefy names "Use IP whitelists" among its API key best practices, describing requests from chosen IPs as ones the system can consider safe. Nothing forces the step, so plenty of integrations ship without it. Adopting the practice from a rotating cloud egress is little better: the list ends up full of ranges you do not own, and the safeguard only holds while those addresses happen to hold still.
Your Payment Stack
checkout · payouts · cron workers
HTTPS Proxy
(Static EU IP)
Corefy
processing.eu.corefy.com
On the Corefy side, every request your systems make arrives from the same two EU addresses, whether it left a container, a scheduler, or a batch job. Both sit in the key's own whitelist, so a proxy node failing over changes nothing Corefy can see.
HTTPS_PROXY once in your environment and every Merchant API operation your stack performs, payment requests, payouts, and reconciliations alike, leaves through the same pair.X-AUTH-KEY value and the payment payload stay encrypted past the proxy hop, because the proxy relays ciphertext it cannot open.Both fixed addresses go into the key's Additional settings once, via Add IP value. Deploys, autoscaling events, and infrastructure migrations stop touching the Corefy dashboard entirely, because the origin the keys expect is the origin that answers.
Corefy's own design decisions, immutable permissions and a one-time key display, push teams toward long-lived keys. A fixed address list is the natural companion: the key stays valid, the whitelist stays true, and neither needs a regeneration ceremony.
The documented Merchant API server is processing.eu.corefy.com, an EU processing cluster, and checkout links resolve at checkout.eu.corefy.com. Egress from European addresses keeps the whole network path coherent, and the same pair clears other orchestrators: see our IXOPAY static IP guide.
Teams whose Corefy traffic has to arrive from an address the key already lists, on every single call.
Payment requests carry a currency, an amount, a strategy such as direct or verify, and your own order and account references, and the resulting checkout link lives at checkout.eu.corefy.com. Every hop in that flow is an authenticated call your servers originate, so every hop needs the trusted address.
Whitelists are per key, and keys are per merchant account. A platform running several accounts, live and test keys side by side, enters the same pair everywhere once and never thinks about which environment a call came from again.
Batch payouts and reconciliation runs fire on calendars, often at hours nobody is watching. A rejected call at 3 AM because the egress rotated is a failed run discovered in the morning; a fixed pair removes the failure mode entirely.
Pods and functions that scale to zero and back have no stable address of their own to whitelist. The proxy gives the whole fleet two shared origins, the same approach our Kubernetes static IP guide walks through in detail.
One environment variable routes every X-AUTH-KEY authenticated Corefy call out of your fixed EU address.
Set the variable wherever your payment code runs. The Merchant API expects the X-AUTH-KEY header on every request, and the proxy alters neither the header nor the body.
# .env, task definition, or Kubernetes secret, wherever env config lives
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
# create a payment request, now egressing from your static EU IP
curl -s "https://processing.eu.corefy.com/api/v1/payment-requests" \
-H "X-AUTH-KEY: $COREFY_API_KEY" \
-H "Content-Type: application/json" \
-d @payment-request.json
# the same pair serves your live and test keys alikePlain requests picks up HTTPS_PROXY from the environment on its own, no extra wiring.
import os
import requests
# requests reads HTTPS_PROXY from the environment automatically
# required attributes per the docs; nothing invented here
payload = {
"data": {
"type": "payment-requests",
"attributes": {
"test_mode": True, # flip to False with a Live key
"origin_reference_id": "order-1234", # your order ID
"reference_id": "acct-primary", # the merchant account
"currency": "EUR",
"strategy": "direct",
"amount": "93.45",
},
},
}
resp = requests.post(
"https://processing.eu.corefy.com/api/v1/payment-requests",
json=payload,
headers={"X-AUTH-KEY": os.environ["COREFY_API_KEY"]},
)
resp.raise_for_status()Node's built-in fetch ignores proxy environment variables, so hand it undici's ProxyAgent explicitly.
import { ProxyAgent } from 'undici';
const res = await fetch('https://processing.eu.corefy.com/api/v1/payment-requests', {
method: 'POST',
dispatcher: new ProxyAgent(process.env.HTTPS_PROXY),
headers: {
'X-AUTH-KEY': process.env.COREFY_API_KEY,
'Content-Type': 'application/json',
},
body: JSON.stringify(payload), // same shape as above
});Both addresses, one save, and the key trusts your whole fleet for the rest of its long life.
# whitelisting the pair, once per API key:
# open the Corefy Dashboard and go to the Merchants tab
# click the Merchant account, then its Developers tab
# click the API key on the grid
# in Additional settings, click Add IP value
# enter BOTH fixed IPv4 addresses, or one range covering both
# Save changes, and repeat for every key in use
# Corefy's own best-practice list includes "Use IP whitelists",
# so this step doubles as following the vendor's guidance. Note
# the asymmetry: permissions freeze at key creation, but the IP
# whitelist stays editable, which is exactly why it pays to fill
# it with addresses that will never need editing againBoth IPs belong to the key from the first request
Every account gets its own pair of static EU IPv4 addresses. Enter both through Add IP value once per key, and the per-key lists stop being a maintenance surface: redeploys, scale-outs, and region moves all present the same two addresses, and a failover between nodes never reopens a whitelist.
Which traffic is covered? Outbound, X-AUTH-KEY authenticated HTTPS against the Corefy Merchant API at processing.eu.corefy.com/api/v1, plus any other Corefy endpoints your services call, initiated by your servers, containers, and cron jobs. Webhooks run the other direction: Corefy delivers events to your endpoints as inbound traffic, so nothing flowing into your systems traverses the proxy and no source-IP rule is needed on that side.
📖 Complete Documentation: For detailed examples, error handling, and advanced configurations, see the Python guide, the Node.js guide, or all guides.
Corefy states strict adherence to GDPR data protection principles and holds PCI DSS Level 1 certification with a v3.2.1 certificate confirmed by independent audit. The first leg of that journey, the one your servers travel, is the part you control.
Payment requests can carry customer emails, names, billing and shipping addresses, and free-form metadata, and much of that is personal data. Egress from European addresses keeps the outbound leg of every one of those calls inside Europe, which is the story a privacy team wants to hear.
Orchestrated payment flows put transaction data in scope and PCI DSS framing around the whole chain. A fixed, documented egress pair is easy to describe in an assessment, and your X-AUTH-KEY travels inside TLS the proxy passes through untouched, so card and transaction data stay encrypted end to end.
Both fixed IPs sit in each key's Additional settings, so the list you save is the list that stays true, no matter how many services, jobs, or regions originate the calls.
Since permissions cannot be edited after creation, regenerating keys is expensive. With the pair in place, infrastructure changes never give you a reason to: the whitelist matches the reality it described on day one.
The two addresses back each other up inside the whitelist each key already carries, so a proxy node stepping out is invisible to the payment pipeline and to the dashboard.
A pod, a region, or a cron worker created tomorrow inherits the fixed pair the moment it starts, and the list you saved on launch day still covers every origin at a hundred times the traffic.
Corefy shows each key value exactly once, which makes protecting it matter even more. Yours travel as an X-AUTH-KEY header inside TLS the proxy relays as ciphertext, and stay in env vars, never in code.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
A single environment variable points every Corefy Merchant API call at two fixed EU addresses each of your keys already lists, from the first test-mode request to the ten-thousandth live payout.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Yes, and the whitelist is attached to each API key individually. In the Corefy Dashboard, open the Merchants tab, click the merchant account, go to its Developers tab, click the API key, and use Add IP value inside Additional settings to enter single addresses or whole ranges. Corefy also lists "Use IP whitelists" among its API key best practices, so configuring it aligns with the vendor's own guidance.
Set HTTPS_PROXY once in the environment where your payment code runs. curl and Python requests honor the variable automatically; Node's built-in fetch needs an explicit undici ProxyAgent. Because TLS passes straight through, the X-AUTH-KEY header and the JSON payload reach Corefy exactly as your code sent them, just from a fixed EU address.
All outbound HTTPS your stack initiates: the Merchant API at processing.eu.corefy.com/api/v1 and any other Corefy endpoints you call, under live and test keys alike. Corefy webhooks are inbound deliveries to your own endpoints, so they do not traverse the proxy and need no source-IP configuration on your side.
Tell us what your orchestration stack runs on, and we will map exactly where the pair plugs in.
Contact Our Founders →