Going Live from Sandbox

When your integration is thoroughly tested against the emulation engine, moving to production requires only three changes. This page covers what those changes are, what to double-check before you make them, and how to verify the transition succeeded.

📘

The zero-code-change guarantee. Because the staging and production environments share identical API endpoints, data structures, response shapes, and request payloads, your application code requires no modification. Only configuration changes — credentials and the base URL — distinguish a staging deployment from a production one.

Step 0: Compliance audit and authority to proceed

Before any production credentials are issued and before you make the three configuration changes below, the Axys platform's technical compliance auditor reviews your staging activity to assess go-live readiness and formally authorize production access.

This is not an automated check — it is a human review of evidence that your integration has been meaningfully tested and behaves correctly across the scenarios the auditor expects to see:

• API call traces — the sequence and volume of calls made against staging, confirming the integration exercises the flows relevant to your Program's design
• Structured logs and records — evidence that state transitions (cardholder compliance outcomes, card lifecycle events, deposit flows, transaction recording) have been correctly observed and handled by your integration
• Error handling coverage — confirmation that non-happy-path scenarios (compliance declines, balance polling under delay, OTP expiry, etc.) have been tested and handled correctly
• Reconciliation — evidence that transaction, fee, and wallet-movement data has been queried and correctly processed

flowchart LR
    A["Integration built\nagainst staging"] --> B["Staging activity reviewed\nby technical compliance auditor"]
    B --> C{"Sufficient\nevidence?"}
    C -- "Yes" --> D["Authority to proceed\ngranted"]
    C -- "No" --> E["Test script(s)\nrequired"]
    E --> B
    D --> F["Production credentials\nand setup proceeds"]

If staging activity is insufficient

If the auditor determines that your staging activity doesn't provide sufficient demonstrable coverage of the required flows, you will be asked to perform specific test scripts before authority to proceed is granted. These scripts are designed to produce the traces, logs, and state evidence the auditor needs to see.

🚧

Plan for this gate in your project timeline. Authority to proceed is not granted automatically on request — it follows the auditor's review of actual staging evidence. If your integration has been developed and tested thoroughly against the emulation engine (as described in Testing Your Integration), the review will typically confirm readiness quickly. If staging has been used lightly or only for happy-path flows, additional test scripts will be required before proceeding.

The Testing Your Integration test matrix and the Testing Your Integration automated test suite guidance are both designed with this gate in mind — integrations that work through the full matrix will have substantially more staging evidence, and therefore a smoother audit, than those that tested only the minimum happy path.

The three changes

flowchart LR
    subgraph Before["Staging"]
        B1["Base URL:\nstaging.api.axyscards.com/v2"]
        B2["Certificate:\nstaging-cert.pem + staging-key.pem"]
        B3["API key:\nYOUR_STAGING_API_KEY"]
    end
    subgraph After["Production"]
        A1["Base URL:\nproduction.api.axyscards.com/v2"]
        A2["Certificate:\nproduction-cert.pem + production-key.pem"]
        A3["API key:\nYOUR_PRODUCTION_API_KEY"]
    end
    Before -->|"Change these three\nand nothing else"| After

Everything else — your request construction, response parsing, polling logic, error handling, webhook handlers, reconciliation code — is unchanged.

Production-only setup (before you go live)

Several things cannot be configured in staging and must be completed in Account Management in the production environment before going live. If you haven't done these, your first production API call will fail:

See Set Up a New Program and the Program Launch Checklist for the complete pre-launch runbook.

What the emulation engine does NOT test

Understanding the boundaries of the staging emulation is important before going live. The following production behaviors have no staging equivalent — be aware of them:

Verifying the transition

Once you've made the three configuration changes and completed production setup:

Step 1: Confirm authentication

curl --cert production-cert.pem \
     --key production-key.pem \
     -H "X-API-Key: YOUR_PRODUCTION_API_KEY" \
     "https://production.api.axyscards.com/v2/cardholders"
# Expected: 200 {"status":"success","items":[],"total":0,...}

A 200 response confirms all three layers (certificate valid, IP allowlisted + FCrDNS passing, API key valid) are working. If this fails, see Authentication & Environments and IP Allowlisting & Network Security.

Step 2: Confirm simulation endpoints are absent

curl --cert production-cert.pem \
     --key production-key.pem \
     -H "X-API-Key: YOUR_PRODUCTION_API_KEY" \
     -X POST "https://production.api.axyscards.com/v2/staging/kyc/validate" \
     -d '{"cardholderId": 1, "result": "pass"}'
# Expected: 404

A 404 confirms you're on the production environment — the simulation endpoints don't exist here. If this returns 200, your base URL is still pointing at staging.

Step 3: First live cardholder

Onboard a real test cardholder — either an internal team member or a designated test identity — using real identity documents. Confirm:

• KYC submission proceeds through the full Didit/SumSub flow
• status = 1 is reached after genuine identity verification
• A virtual card can be issued and its deposit address displayed

Environment guard in your test suite

If you built an automated test suite in staging (see Testing Your Integration), add an environment guard so it can never run against production credentials:

// Guard at the top of every test file
if (process.env.AXYS_ENV !== 'staging') {
  throw new Error(
    'Integration tests must only run against the staging environment. ' +
    'Set AXYS_ENV=staging and AXYS_API_KEY to your staging key.'
  );
}

The /staging/* simulation endpoints will return 404 in production regardless, but this guard prevents test setup code (cardholder creation, etc.) from polluting production data.

What's next

• Program Launch Checklist — the complete pre-launch runbook
• Authentication & Environments
• IP Allowlisting & Network Security
• Credentials & Key Rotation