Production Launch Checklist for Strails

Before switching from the Strails staging environment to production, work through every section below. Each item represents a real failure mode caught during past integrations - don’t skip them.

​

1. Credentials & Environment

• You have received a production API key from Strails via the secure onboarding process.
• You have switched your base URL from https://sandbox.strails.io/v1/ to https://api.strails.io/v1/ in every service and configuration file that calls the Strails API.
• Your production API key is stored in a secret manager (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, or equivalent) and is not present in source control, .env files committed to git, or CI/CD logs.
• If your production API key was ever shared, emailed in plaintext, or accidentally exposed, you have regenerated it before going live.

​

2. IP Allowlisting

• You have retrieved the public IP address(es) of all production servers and load balancers that will call the Strails API.
• You have added those IPs to your production allowlist via /manageipallowlist or by sending them to Strails support.
• You have made a test request from production (not from your laptop or staging) to confirm that the allowlist is active and correct.

​

3. Payload Encryption

• You have generated a production Ed25519 key pair separate from any key pair used in staging.
• You have registered your production public key with Strails by calling POST /storepublickey. Strails uses this key to encrypt all responses sent back to your integration.
• You have received the production Strails public key and stored it securely.
• You have verified encryption and decryption round-trips end to end - encrypt a payload in your production environment and confirm Strails can process it, and vice versa.
• Your production services use the production X25519 keys, not staging keys.

See Encryption for key generation, POST /storepublickey registration, and payload signing details.

​

4. Webhooks

• You have registered a production HTTPS webhook URL via /setwebhook. The URL must be publicly reachable and serve a valid TLS certificate.
• Your webhook handler returns 200 OK immediately and processes all event logic asynchronously to prevent Strails from treating slow responses as failures.
• You have configured a strong, randomly generated webhook secret (at least 32 bytes of entropy) and stored it in your secret manager.
• Your handler verifies X-Strails-Signature using HMAC-SHA256 on every incoming request and rejects requests that fail verification.
• Your handler rejects requests where X-Strails-Timestamp is more than 5 minutes old to prevent replay attacks.
• You have confirmed that your handler processes all critical event types your integration depends on (for example, user.onboarded, wallet.funding.completed, swap.completed, vault.return.payout.completed, fintech.offramp.completed). FX trades emit no webhooks - poll GET /fx/trades/status instead.

See HMAC Signatures and Webhook Events for payload schemas and the full event list.

​

5. Wallets & Liquidity

• You have called /getfintechwallet against the production environment and confirmed your Smart Wallet address is present, and retrieved your MPC Vault token wallets from /fx/settings.
• You have verified that your MPC Vault is registered and that auto-signing is configured correctly for FX trading.
• You have retrieved your FX settings via /fx/settings, noted the natExternalIp value, and whitelisted that IP in MPCVault.
• You have confirmed that your production wallets hold sufficient cNGN and USDC/USDT liquidity to cover the transaction volumes you expect at launch.
• You understand that active FX orders lock the corresponding wallet balances and have accounted for this in your liquidity planning.

​

6. Fees & Bank Accounts

• You have reviewed your current fintech fee configuration via /getfees and confirmed the fee values match your product pricing.
• You have set your production fee structure via /managefees.
• You have added and verified your production settlement bank account via /addbankaccount.
• You have processed a small-value offramp (₦100-₦500) end to end in production to confirm that settlement reaches the correct bank account.

​

7. End-to-End Testing

Run all of the following flows at least once against the production environment before you open up to real users:

• User onboarding: BVN submission -> verification -> user.onboarded webhook event received.
• Virtual account creation: Onramp initiation -> account details returned -> account expires correctly after 30 minutes if unused.
• Wallet funding (onramp): NGN deposit received -> cNGN disbursed -> wallet.funding.completed webhook event received -> balance visible on wallet.
• Auto-swap: Onramp with autoSwap: true -> cNGN disbursed -> USDC/USDT credited -> swap.completed webhook event received.
• User default wallet (if used): External wallet set via /setuserdefaultwallet -> onramp completed -> cNGN confirmed at the external address -> wallet removed -> funding confirmed to revert to the Strails-managed wallet.
• Withdrawal (offramp): Offramp initiated -> bank transfer processed -> vault.return.payout.completed (user offramp) or fintech.offramp.completed (fintech offramp) webhook event received -> correct amount credited to bank account.
• FX trading: Limit order posted -> quote fetched -> trade executed -> GET /fx/trades/status polled through to completed -> both wallet balances updated correctly.

​

8. Monitoring & Support

• You have logging in place that records every Strails API request and response, including requestId values, HTTP status codes, and response times.
• You have alerting configured to notify your on-call team when API error rates exceed a threshold or when critical webhook events stop arriving.
• You have a runbook documenting how to handle 429 Too Many Requests responses - at minimum, implement exponential backoff with jitter and document how to request a rate limit increase.
• You know how to reach Strails support: support@strails.co.

---