IP Whitelisting¶

IP whitelisting is enforced in production only. A production request from a non-whitelisted IP receives 403 Forbidden with {"success": false, "message": "Unauthorized request."} (see Errors & Status Codes). The whitelist is tracked per application, meaning per client ID/secret pair Hivemind Payments issues you.

Sandbox does not enforce it¶

Sandbox credentials work from any address. You can develop from a laptop, from CI, from a coffee shop, without registering anything.

This is a convenience with one sharp edge, so it is worth being explicit about: an integration that works perfectly in sandbox will be refused on its first production request if you have not whitelisted an address. In production the check fails closed — an application with no whitelist entries is denied everything, rather than allowing everything.

That is why registering at least one address is part of the go-live checklist: you meet the requirement deliberately, while you are still testing, instead of discovering it during your launch.

Before going live¶

• Add your server's static outbound IP(s) in the merchant portal, under your production application. You can add and remove entries yourself; you do not need to raise a ticket.
• Whitelists are per application, so your production application's list is separate from anything else. A sandbox application has no list and needs none.
• Use a static IP or NAT gateway if your infrastructure has dynamic egress IPs. This matters especially for serverless platforms and autoscaling groups, where outbound IPs can change between requests unless explicitly pinned (e.g. via a NAT gateway or static egress IP feature of your cloud provider).
• A blacklist entry always wins. If an address appears on both lists, it is refused.

See also Token Handling Best Practices for the other half of securing production access.