Security

Security on the IBANQ platform rests on keys you generate and hold, not on shared secrets. You never send us a password or a client secret, and we never send you a webhook token. Every request you make is proven with a signature from a private key that stays in your infrastructure, and every webhook we send is signed with a private key that stays in ours. Anything that cannot be verified should be rejected.

Transport

Everything runs over HTTPS with publicly trusted certificates. The API does not accept plain HTTP, and we will not connect to a webhook endpoint over plain HTTP. We also do not follow redirects, so an http to https redirect in front of your receiver is a failed delivery rather than a recovered one.

Authenticating to the API

Access tokens come from the OAuth 2.0 client credentials grant, and your client is authenticated with a signed JWT assertion rather than a secret. The assertion identifies you by your application ID, which is the only identifier the token endpoint accepts: your client ID is used inside API requests, never to obtain a token. Nothing you hold as a password ever crosses the wire. Tokens are short lived and sender constrained with DPoP, so a token on its own is not enough to make a call. Each request carries a fresh DPoP proof signed with your DPoP key and bound to that exact method and URL. Proofs are single use, and replays are rejected.

Scopes decide what a token can do, and Auth0 returns every scope delegated to your application. The scope parameter on the token request cannot narrow that down, so the scopes a token carries are always the ones delegated to you at onboarding. If you need that set changed, reach out to your account manager to adjust your delegated scopes.

Signing requests that move money

Endpoints that move money need more than a valid token. They require an HTTP message signature and a content digest taken over the exact bytes of the request body, using your registered signing key. The method, target URI, content type and body are all covered, so the request is tamper evident in transit and we can show later that it came from you. The signature timestamp has to be within sixty seconds of server time, which leaves very little room for a captured request to be replayed. Read endpoints, payee management and account name verification do not need a signature.

Signing is paired with idempotency. Outbound and internal payments take an idempotency key you choose, so if you lose a response and retry, you get the original payment back instead of sending a second one. Retries stay safe, which matters more than it sounds when the alternative is a duplicate payment.

Keys and rotation

You generate three key pairs in your own infrastructure: an authentication key for the client assertion, a DPoP key for proofs, and a signing key for request signatures. Only the authentication and signing public keys are registered with us. The private halves never leave your side, and we will never ask you for them.

Keep those private keys in a secret manager or an HSM rather than in source control, build logs or environment files that get copied between machines. Use separate keys for sandbox and production. Rotation is designed to be done without downtime: two authentication keys and two signing key ids can be registered at the same time, so you register the new one, switch your client over, confirm traffic is flowing, then ask for the old one to be retired. The DPoP key is not registered with us at all, so you can rotate it freely, though you should keep the old key until any tokens bound to it have expired.

Webhook security

Your webhook URL is public. Anyone who finds it can post to it, so the signature on each delivery is what separates a real event from a forgery. Every delivery is signed with our private key over the method, host, request target, a digest of the exact body, and the delivery, attempt and group headers. You verify it with our public key set, which is published at the well-known JWKS path on the API host, is anonymous to fetch, and should be cached and refreshed rather than pinned to one key.

There is no shared secret in this scheme. We never send you a token or a password for webhooks, so there is nothing on your side for an attacker to steal and nothing on ours to leak. Our signing keys rotate annually with a thirty day overlap, and a client that caches the key set correctly never notices.

Three habits cover most of the risk. Verify the signature before you read the body, and reject anything that fails with a 401. De-duplicate on the envelope id, because the same event can legitimately arrive more than once. Treat the payload as a notification rather than as the truth, and fetch the object from the API before you act on money.

The signature timestamp is stamped at each attempt and checked within a five minute window, so a captured delivery cannot be replayed at you later. Duplicates from us are normal and are not an attack: a timed-out attempt may have succeeded on your side, support can replay a delivery, and version migrations can send the same event under two type names. Key on the envelope id and make your handler idempotent.

Do not allowlist by source IP. We do not publish a fixed range of source addresses, and the signature rather than the network path is the authentication.

Your side of the line

We can only secure our half. The habits below are what keep the other half sound.

• Store private keys in a secret manager or an HSM, one set per environment, and never in source control.
• Keep your delegated scopes as narrow as the integration needs, and reach out to your account manager to adjust them if that changes.
• Verify every webhook before you process it, and fail closed. If verification cannot run because the key set is unreachable, return a 5xx and let the retry ladder bring the event back.
• Keep secrets and tokens out of URLs and query strings. They end up in access logs, browser history and referrer headers.
• Do not log raw request or webhook bodies in production. They carry account identifiers and amounts.
• Keep your clocks in sync with NTP. Signature windows are tight, and clock drift produces failures that look like an attack.
• Point one URL at one purpose. If a shared path also accepts unsigned traffic, the weakest handler behind it defines your security.
• Prove the whole flow end to end in the sandbox before you register a production endpoint or move real money.

If something goes wrong

If you think a private key has been exposed, or you see API traffic or webhook activity you cannot account for, contact your IFX Payments representative straight away. A key can be retired and a replacement registered quickly, and the sooner that happens the smaller the window. If you believe you have found a weakness in the API or in webhook delivery, report it the same way rather than testing it against production.

Repeated rejections are worth treating as an incident rather than noise. Ten consecutive failed deliveries open the circuit breaker on a webhook endpoint, and five days without a single success disables it until your representative turns it back on. A verification bug and an attack look identical from the outside, so investigate either way, and quote the delivery id when you get in touch.

Where next

• API Authentication: the full key, token, DPoP and request signing reference.
• Securing your webhook endpoint: signature verification step by step, with Node and Python examples.
• Going from sandbox to production: what changes at go-live, and what to check before you get there.