Welcome to the Axys Cards API Gateway
Welcome to the Axys Cards API Gateway developer portal. Axys is a turnkey aggregation, automation, and orchestration layer for card issuing — unifying and systemizing the Issuer, Program Manager, and Issuer Processor roles, with built-in network, payment, and digital asset rails, so that a single card balance can be funded, held, and spent across both traditional banking and blockchain networks without the integrator needing to build or coordinate separate systems for each.
This page gives you the lay of the land. If you're setting up a new Tenant or Program from scratch, or you already hold program-level API Key credentials and just want to make your first call, both paths are covered below.
Architecture at a glance
This is a multi-tenant platform, each running one or more card programs.
flowchart LR
A["Platform"] --> B["Tenant"]
B --> C["Program"]
C --> D["Cardholder"]
D --> E["Cards, Accounts & Wallets"]
This is the short version. For the full hierarchy, terminology, and how credentials map to each layer, see Program Architecture. Everything else in these docs assumes you're familiar with that page.
What you can build
| Capability | What it covers |
|---|---|
| Cardholder onboarding & compliance | KYC/KYB via hosted Didit verification or a SumSub token flow, with a status-driven approval lifecycle |
| Card issuance & lifecycle management | Issue virtual Cards instantly or physical Cards for fulfillment; activate, set card PINs, adjust limits, block/unblock |
| Automatic multi-chain funding | Every Card receives unique deposit addresses across up to 80+ blockchains and 3,000+ digital assets at the moment it's issued — no separate registration step |
| Bank-rail funding | Register a Cardholder's external bank account (OTP-verified) for traditional deposits, with optional trace notifications for faster processing |
| Wallets & internal transfers | Create fiat sub-ledgers for corporate, departmental, or family use cases, and move funds between wallets and cards |
| Transactions, fees & reconciliation | Query card and wallet transaction and fee history with rich filtering for reporting and reconciliation |
| 3-D Secure | Subscribe to one-time-passcode delivery (poll or webhook) for card-not-present authentication |
| Program configuration | Configure Card Designs, currency, and transaction-limit ceilings for each Program |
What makes the platform different
A few aspects of the platform are worth understanding early, because they shape how several Concepts pages are written:
A Card's balance is a single, unified ledger: regardless of whether it's funded by a bank transfer or by a digital asset deposit, both rails land in the same Card Account, converted dynamically to the Program's base currency. Integrators don't need to reconcile separate fiat and crypto balances. See Accounts, Wallets & Deposit Addresses.
Digital asset funding is automatic and zero-integration: when a Card is issued, the platform generates a unique Deposit Address for each supported chain immediately. There's no address registration call to make; you simply retrieve and share the address. See Funding & Deposits.
Settlement is T+0: funds move into a Card's availableBalance, and fees are settled to the Tenant and Program, on a same-day basis rather than the multi-day settlement cycles common in traditional card programs. See Transactions & Fees.
Digital asset custody is institutional-grade: private keys are never held in a single location; key shares are distributed using HSM-backed Multi-Party Computation (MPC) with a Threshold Signature Scheme (TSS) across independently regulated parties. See Security, Compliance & Data Protection.
Currencies beyond USD/EUR/GBP/CAD are supported natively: including emerging-market currencies, without the need to convert to the Program's base currency before they can be held or spent.
Express Cardholder onboarding and card issuance: aside from edge cases, a Cardholder's onboarding process can be completed straightforwardly and programmatically in only a few minutes, and Cards can be issued instantly.
Issuing is global by default: Programs can onboard Cardholders and issue Visa and Mastercard cards without being restricted to specific jurisdictions, beyond standard OFAC sanctions screening and case-by-case compliance matters.
There's no platform-imposed ceiling on loads or spends: beyond whatever transactionLimit is configured for a Program, a Cardholder or a Card, and the variability and limitations of the Card Network, the platform does not impose its own limits.
Dynamic Currency Conversion is built into every deposit and transaction: funds can originate in practically any source fiat currency or digital asset and are converted into the Card's base currency automatically.
Compliance and infrastructure assurance is built in: the platform runs on PCI-DSS, ISO 27001, SOC 2, and Uptime Institute–compliant infrastructure, with a 99.99% uptime commitment (less than 53 minutes of unplanned downtime per year). See Security, Compliance & Data Protection for the full picture (this page will expand as further detail becomes available).
Where to start
Setting up a new Tenant or Program:
Start with Platform Onboarding: Overview & Checklist. You'll need to generate a Certificate Signing Request (CSR), receive your mTLS client certificate, and configure the IP allowlist before any API calls (including staging calls) will succeed.
Already holding Program-level credentials and a client certificate:
Head to Authentication & Environments, then Your First API Call.
How these docs are organized
| Section | What's in it |
|---|---|
| Getting Started | This section: authentication, your first call, errors, pagination, and versioning |
| Onboarding and Security | mTLS certificates, IP allowlist configuration, credential rotation, and the platform's security/compliance posture |
| Core Concepts | The object model: Programs, Cardholders, Cards, Accounts, Wallets, Deposit Addresses, Transactions, Fees, 3-D Secure, Card Designs |
| How-To Guides | Step-by-step, task-oriented walkthroughs |
| Sandbox Emulator | How the staging emulation engine works, and how to test your integration against it before going live |
| Cookbook | Full, runnable, multi-step code examples |
| Industry Fundamentals | Vendor-neutral background on how card transactions, interchange, FX, and digital asset rails work generally — useful even if you're new to card issuing as an industry |
| Reference | The complete API Reference, plus error/status code tables, a glossary, and an index |
Environments
The platform provides separate staging, sandbox and production environments, each with its own base URL, API Key, and mTLS certificate:
| Environment | Base URL |
|---|---|
| Staging | https://staging.api.axyscards.com/v2 |
| Sandbox | https://staging.api.axyscards.com/v2/sandbox |
| Production | https://production.api.axyscards.com/v2 |
Full details, including how authentication works across both, are covered in Authentication & Environments.
What's next
- Program Architecture — the hierarchy and terminology used throughout these docs
- Platform Onboarding: Overview & Checklist — for new Tenants and Programs
- Authentication & Environments — for developers ready to make their first call
Updated about 1 month ago
