Skip to main content

Go-live checklist

Before we enable production access, we check the items below. Going through them yourself first usually makes the approval process faster.

Commercial and regulatory​

  • Business verification (KYB) complete
  • Contract signed
  • Program configured: BIN range, card products, currencies, fee schedule
  • Limits agreed: per-card, per-cardholder, per-program
  • Named operational contact and escalation path on file
  • Where you perform identity verification yourself, your KYC policy reviewed

Credentials and access​

  • Production OAuth client registered, and its private key never committed to source control
  • Private key read from a secrets manager or environment, not from configuration files in the repository
  • Separate clients per deployment target, each labeled
  • Key rotation procedure written down and tested at least once
  • IP allowlisting configured for the environment (self-serve in Cockpit), both the organization-wide policy and, where needed, a per-client allowlist
  • Access controls for Cockpit users agreed, including MFA and least-privilege roles
  • No shared logins or shared credentials between deployment targets

Integration correctness​

  • Idempotency-Key sent on every POST, not just the ones that seem risky
  • Retry logic uses exponential backoff and respects Retry-After
  • 401 and 403 are not retried
  • Money handled as integer minor units end to end, with no floats anywhere in the path, including database columns and JSON parsing
  • available_balance used for anything a user sees; ledger_balance used for reconciliation
  • Unknown enum values tolerated rather than causing errors. We may add enum members in minor releases
  • Aleta-Request-Id captured and logged on every response, both success and failure

Webhooks​

Operational readiness​

  • Someone owns the integration and is reachable outside office hours
  • Support process defined, and everyone who raises tickets knows that request_id is mandatory
  • Reconciliation runs on a schedule and someone reviews the breaks
  • Dashboards cover transaction volume, webhook delivery success, and API error rate
  • Card lifecycle actions (freeze, replace, close) reachable by your support staff without an engineer
  • Runbook exists for: a cardholder reporting a lost card, a disputed transaction, and a suspected key compromise

Security and compliance​

  • PCI DSS scope understood and documented on your side
  • Full card numbers never logged, never stored, never sent to analytics
  • PAN masked by default in every internal tool
  • Card reveal, if you offer it, behind step-up authentication and audited
  • Cardholder PII encrypted at rest in your systems
  • Data retention and deletion policy agreed

Final verification in sandbox​

Before requesting production, confirm the full flow in sandbox:

  • Cardholder created and verification completed through the webhook path, not the synchronous response
  • Account funded, card issued, card activated
  • A card payment settled and posted from amount, which can differ from what the terminal displayed
  • Card frozen, unfrozen, replaced, and closed
  • Dispute opened and evidence submitted
  • Every webhook event type your integration subscribes to received and processed

Requesting access​

When the list is complete, request production access from your relationship manager. We review it and either provide the credentials or let you know what is still outstanding.

Last updated on