Program Launch Checklist (Go-Live Runbook)

This runbook covers everything required to take a Program from staging integration to production go-live. It's organized into four phases: staging completion, production onboarding, production verification, and launch day. Work through each phase in order — steps in later phases depend on earlier ones being fully complete.

Phase 1: Staging completion

Complete these in staging before touching production. Staging uses the base URL https://staging.api.axyscards.com/v2 and its own separate credentials.

Integration completeness

• POST /cardholders — cardholder creation tested with all required fields
• PUT /cardholders/{id}/kyc-submit — compliance submission tested; staging approval received
• GET /cardholders/{id} — polling loop implemented and tested
• POST /cards/virtual/{cardholderId} — virtual card issuance tested
• POST /cards/assign/{cardholderId} — physical card issuance tested (if applicable)
• PUT /cards/{cardId}/activate — physical card activation tested (if applicable)
• GET /cards/{cardId}/balance — balance polling implemented
• GET /cards/{cardId} — deposit addresses confirmed in response
• PUT /cards/{cardId}/status — block/unblock tested
• PUT /cards/{cardId}/update — alias and limit update tested
• PUT /cards/{cardId}/pin — PIN change tested (if applicable)
• POST /cardholders/{id}/register-bank-account — bank account registration tested (if applicable)
• POST /cards/{cardId}/bank-deposit — trace notification tested (if applicable)
• POST /wallets — wallet creation tested (if applicable)
• POST /wallets/transfer — wallet-to-card transfer tested (if applicable)
• GET /cards/transactions + GET /cards/fees — pagination and correlation tested
• POST /otp/listeners + GET /otp/{token} — 3DS OTP flow tested (if Program has 3DS enabled)

Error handling

• All API error responses handled — at minimum, 400, 401, 403, 404, 409, 422, 429, 5xx
• The two-cause 403 "No Authorised IPs configured" distinguished in error logs
• Compliance decline path (status = 2) implemented — KYC URL refresh or support ticket
• Admin decline path (status = 7) implemented — support ticket
• Transfer idempotency guard implemented — no blind retries on POST /wallets/transfer
• Support ticket endpoint (POST /support/tickets) implemented for escalation paths

Security review

• mTLS private key stored in secrets manager — not hardcoded, not committed to source control
• X-API-Key stored in secrets manager — not hardcoded, not in client-side code
• GET /cards/{cardId}/details response (full PAN/CVV) never logged
• OTP subscription tokens encrypted at rest

Phase 2: Production onboarding (Account Management)

All of the following require production Tenant credentials and Account Management access.

🚧

Authority to proceed required before production credentials are issued. The Axys platform's technical compliance auditor must review your staging activity — API call traces, structured logs, state-transition records, and error-handling evidence — and formally authorize production access before this phase can begin. If staging activity is insufficient, you will be asked to perform specific test scripts. See Going Live from Sandbox.

Certificates

• Tenant certificate: already issued during initial Axys onboarding
• Program certificate: CSR generated, submitted via Account Management, signed cert received
• Cert validity verified (openssl x509 -in program.crt -noout -dates)
• Key-cert modulus match confirmed (openssl x509 ... -modulus | md5sum and openssl rsa ... -modulus | md5sum — both hashes identical)
• Certificate expiry reminder webhook URL registered in Account Management
• Certificate expiry registered in your internal certificate register

Network security

• Production calling IP(s) identified (NAT Gateway EIPs or equivalent — static, known)
• IP(s) submitted for allowlisting via Account Management
• A records: each CN/SAN domain resolves to the calling IP(s)
• PTR records: each calling IP resolves back to a domain in the certificate (cloud provider support ticket required for EIPs in most cases)
• FCrDNS test passed: dig +short <domain> and dig +short -x <ip> results are consistent
• Test confirmed: production cert + key + allowlisted IP → GET /cardholders returns 200

Program configuration

• Program created in Account Management with confirmed base currency and transaction limit ceiling
• Base currency confirmed — cannot be changed after Program creation
• Transaction limit ceiling set correctly (decimal-implied — e.g. 500000 = $5,000.00 USD)
• 3-D Secure enabled / disabled as required for this Program
• Fee structure configured: all fee types, rates, and Tenant/Program fee-share splits reviewed
• Billing cycle and settlement currency/asset confirmed

Card designs

• Card Design slot 0 (mandatory default) artwork submitted
• Card Design slot 0 approved (designStatus = 1) — physical cards cannot be issued until this is approved
• Additional design slots (1–5) submitted and approved if required

Deposit addresses and funding

• Default deposit address types (EVM, BTC, SOL) confirmed adequate — or additional types requisitioned
• Program inbound bank credentials retrieved from Account Management and noted for cardholder funding UX
• Bank payment reference format confirmed with Axys account team
• SMS sender: anonymous short code (default) confirmed, or named sender application submitted

Phase 3: Production verification

Run these tests in production before directing live cardholders to the Program.

# 1. Confirm authentication
curl --cert program.crt --key program.key \
  -H "X-API-Key: $PROD_API_KEY" \
  https://production.api.axyscards.com/v2/cardholders
# Expected: 200 {"status":"success","items":[],"total":0,"limit":50,"offset":0}

# 2. Create a test cardholder (use real-looking but internally-identified test data)
# Note: record the cardholderId for cleanup

# 3. Submit to compliance — confirm applicationLink is returned
# 4. Use a test identity document to confirm compliance approval
# 5. Issue a virtual card — confirm cryptoAddresses are present
# 6. Retrieve card details — confirm full PAN/CVV returned by GET /cards/{id}/details
# 7. Make a small test transaction if a funded test card is available
# 8. Confirm GET /cards/transactions returns the test transaction

Phase 4: Launch day

Pre-launch (day before)

• All Phase 3 production tests passing
• Support ticket system (POST /support/tickets) tested in production
• Certificate expiry webhook delivery confirmed (test callback received)
• Monitoring / alerting active for 403 and 5xx rates
• Team briefed: who to contact if issues arise (support ticket priority: 1 for critical issues)
• Rollback plan documented: what to do if the production integration has a blocking issue

Go-live

• Switch cardholder-facing flows from staging to production base URL
• Confirm AXYS_ENV environment variable (or equivalent) is set to production in all services
• Monitor error rates for the first hour — 403 spikes indicate IP/cert issues; 4xx spikes indicate request format issues
• First live cardholder onboarded and card issued — manually verified end-to-end

Post-launch (first week)

• Daily reconciliation job running and output reviewed
• Certificate expiry date noted in calendar with 30-day reminder aligned
• Any production issues raised via support ticket — priority: 1 or 2 for blocking issues
• Staging environment kept for ongoing regression testing of new features

Quick-reference: common go-live blockers

What's next

• mTLS Certificates & CSR
• IP Allowlisting & Network Security
• Credentials & Key Rotation
• Support Tickets