Access and environments
Payment API access is provisioned per environment. Start in sandbox and request production access when authentication, payout processing, webhooks, retries, and reconciliation have been validated.
The Payment API spends balances already held in Axiym accounts. It does not provide account-funding instructions or initiate funding. Arrange for the account to be funded before creating or confirming a payment.
What you provide
Give Axiym:
- the stable public egress IP addresses or CIDR ranges used to call the API;
- the client operating model and expected client volume;
- the sell currencies and destination corridors you need; and
- the webhook endpoint and inbound network requirements for each environment.
What Axiym provides
For each environment, Axiym provides:
- the Payment API base URL;
- OAuth
client_idandclient_secretvalues with thePAYMENTscope; - confirmation that the calling egress addresses are allowlisted;
- the partner-owned accounts, balances, and payout corridors available to the partnership; and
- the sandbox party data, documents, outcome controls, and reset process available for testing.
Credentials and resources are not shared between sandbox and production.
Environment endpoints
| Environment | Base URL | API destination IP |
|---|---|---|
| Sandbox | https://partner-api.sandbox.axiym.io/api/v1 | 35.244.214.3 |
| Production | https://partner-api.axiym.io/api/v1 | 34.160.126.192 |
Call the API by hostname. The destination IP is supplied for partners whose outbound firewall policy also requires an IP allowlist.
Network allowlisting
Axiym accepts API requests only from allowlisted source addresses. A request
from another address returns 403 Forbidden, even if the access token is
valid.
Confirm the actual public egress address from every calling runtime. Private container or virtual-machine addresses are not the source address Axiym sees after network address translation.
Before production
- use production-specific credentials, identifiers, accounts, and URLs;
- verify timeout, retry, and idempotency behavior;
- log request IDs without logging secrets or access tokens;
- keep party data and supporting-document content out of general application logs;
- test success, validation, rejection, and ambiguous-response handling;
- run Payout Test for each party-data structure and destination context your integration supports;
- verify webhook signature handling and reconciliation recovery; and
- confirm funded accounts and available corridors with Axiym.