API Users, Tenants & Programs

This page covers the Account Management layer of the Axys platform: what it governs, who has access, how the credential and permission model works across Tenants, Programs, and API users, and what Tenants can see and configure on behalf of their Programs and white-label clients.

❗️

Account Management is not publicly exposed. The Account Management interface and its underlying endpoints are available exclusively to Tenants holding production API keys. They are deliberately absent from the public OpenAPI reference and are not accessible in the staging environment. Full operational guides for Account Management are provided separately to production Tenants. If you are a Tenant and do not yet have access, contact your Axys account team.

The two-tier credential model

As established in Program Architecture, every Axys integration operates with one of two credential scopes:

flowchart TD
    PLAT["Axys Platform"]
    TEN["Tenant<br/>Tenant-level mTLS cert + API key<br/>(production only)"]
    AM["Account Management<br/>(production Tenants only)"]
    PROG1["Program A<br/>Program-level mTLS cert + API key"]
    PROG2["Program B<br/>Program-level mTLS cert + API key"]
    API["Program-level API<br/>(published OpenAPI spec)"]

    PLAT --> TEN
    TEN -->|"accesses"| AM
    AM -->|"creates and configures"| PROG1
    AM -->|"creates and configures"| PROG2
    PROG1 -->|"accesses"| API
    PROG2 -->|"accesses"| API

A Tenant cannot use program-level credentials to perform Account Management operations, and a Program's credentials cannot see or affect any other Program. These are hard boundaries enforced at both the TLS-certificate and API-key levels.

API users

Within each Tenant account, multiple API users can be created — each representing an independent credential set (mTLS certificate + API key) that can be scoped to specific Programs or to Account Management capabilities.

Typical API user patterns

What Account Management governs

Terms of use, SLAs, and legal agreements

Account Management is the canonical location for all legal and contractual documentation governing the Tenant's use of the platform, including:

• Terms of use — the platform's master service and acceptable use terms
• Service Level Agreements (SLAs) — including the platform's 99.99% uptime commitment and the remedies and exclusions that apply — see Security Compliance & Data Protection
• Data processing agreements, regulatory attestations, and any jurisdiction-specific addenda

📘

Acceptance of the platform's terms of use and SLAs is implied by the Tenant's use of the service. Current versions of all agreements are accessible within Account Management for production Tenants.

Program onboarding

Account Management is also where a Tenant completes the technical onboarding of each new Program — including the mTLS and network security steps that, for the initial Tenant onboarding, are handled manually with Axys's team:

sequenceDiagram
    participant Tenant
    participant AM as Account Management
    participant Axys as Axys CA / Platform

    Note over Tenant,Axys: PROGRAM ONBOARDING (self-service via Account Management)

    Tenant->>AM: Create new Program (currency, transaction limit, 3DS, fee structure)
    AM->>Tenant: Program record created — program ID assigned

    Tenant->>Tenant: Generate RSA key pair + CSR for the Program
    Tenant->>AM: Submit Program CSR (PEM)
    AM->>Axys: Forward to CA for signing
    Axys->>AM: Signed program-level certificate
    AM->>Tenant: Program certificate available for download

    Tenant->>AM: Register webhook URL for certificate expiry reminders
    AM->>Tenant: Webhook confirmed

    Tenant->>AM: Register Program's calling IP address(es) for allowlisting
    AM->>Axys: Update WAF allowlist
    AM->>Tenant: IP allowlisted

    Note over Tenant,Axys: Program is now ready for program-level API calls

This self-service Program onboarding covers:

📘

Ongoing Tenant-level certificate and IP management — after the initial manual onboarding of the Tenant itself, renewal of the Tenant's own certificate and updates to the Tenant's own IP allowlist are also handled through Account Management, using the same CSR submission and IP registration workflows described above. See Credentials & Key Rotation and IP Allowlisting & Network Security.

Card Designs

• Submit a Card Design for a specific slot (0–5), including artwork and metadata — see Card Programs & Designs
• Track design approval status (Pending / Approved / Rejected) per slot
• Resubmit a rejected design with revised artwork

Fee structure

• Configure all fee types, rates, and billing triggers for each Program
• Set platform-minimum-compliant fee amounts (the platform enforces minimums that cannot be undercut)
• Set Tenant/Program fee-share splits per fee type
• Configure billing cycle and settlement currency/asset

See Transactions & Fees for the full fee model.

Program monitoring and partner visibility

Tenant-level credentials provide read access across all Programs under the Tenant. This is a materially broader view than program-level credentials, which can only see their own Program's data:

Exposing data to white-label clients

For Tenants operating Programs on behalf of white-label or co-brand clients, Account Management provides controls to determine what a partner can see on a program-specific basis:

• A Tenant can choose to expose a Program's transaction data and balance information directly to the partner operating that Program — for example, providing the partner with a read-only view of their end-cardholders' activity without giving them full Account Management access.
• This is distinct from issuing the partner a full program-level API user (which would give them programmatic access to all program-level endpoints) — it's a view-layer exposure decision, governed by the Tenant.

📘

The specific configuration options for partner visibility — which data surfaces are exposable, at what granularity, and via what delivery mechanism — are covered in the Tenant-level Account Management guides available to production Tenants.

Network security: IP allowlisting

IP allowlisting for both the Tenant itself and each of its Programs is managed within Account Management. The three-layer security model (IP allowlist, mTLS, FCrDNS) applies equally to both levels:

sequenceDiagram
    participant Tenant
    participant AM as Account Management
    participant WAF as Axys WAF / Gateway

    Tenant->>AM: Register calling IP address(es) for a Program
    AM->>WAF: Update allowlist for this Program
    Tenant->>WAF: API request from registered IP (with cert + key)
    WAF->>WAF: Check 1: IP on allowlist ✓
    WAF->>WAF: Check 2: FCrDNS (DNS forward + PTR reverse) ✓
    WAF->>Tenant: Request proceeds

• Staging and production have separate allowlists
• Each calling IP must also pass the FCrDNS check — allowlisting alone is not sufficient
• Cloud provider EIPs typically require a separate request to set a custom PTR record

Full troubleshooting guidance: IP Allowlisting & Network Security.

Network security: blockchain wallet address whitelisting

Account Management also supports a program-level blockchain wallet address whitelist — a list of addresses from which the Program itself expects to interact with digital assets at the platform and operational level. This is distinct from cardholder-level deposit addresses, which are auto-provisioned per card and require no configuration.

Account Management availability

This is a critical operational constraint: all meaningful Program configuration — fee structure, 3DS enablement, card design approval, deposit address types, inbound bank credentials, SMS sender, named certificates — cannot be tested in staging and must be designed and verified as part of the production go-live process.

What's next

• Onboarding Overview & Checklist
• Card Programs & Designs
• IP Allowlisting & Network Security
• mTLS Certificates & CSR
• Transactions & Fees