Go-Live Checklist

Use this checklist to make sure your integration is complete, secure, and production-ready before switching from sandbox to live.

Account & business setup

• Created a production account at app.credocentral.com
• Completed all six onboarding steps: personal profile, business profile, registration documents, business representatives, account information, and charges information
• Business name and details are correct on the dashboard
• Settlement bank account is configured and verified
• Team members have been invited with appropriate roles and permissions
• Two-factor authentication (2FA) is enabled for all team accounts (Optional)

API keys & environment

• Switched from sandbox to production API keys
• Updated base URL from api.credodemo.com to api.credocentral.com
• API keys are stored in environment variables - not hardcoded in source code
• Secret key is only used on the server - never exposed in frontend or mobile code
• Old sandbox keys are not referenced anywhere in production config
• Separate environment configs exist for staging and production

Payment integration

• Payment initialization works with the production endpoint
• All required fields are included in the request (amount, email, currency)
• Amounts are correctly converted to the lowest currency unit (kobo/cents)
• callbackUrl is set to a valid, publicly accessible HTTPS URL
• Customer is redirected to the authorizationUrl after initialization
• Pending payments reuse the existing authorizationUrl instead of creating duplicates
• Payment channels are configured appropriately for your use case
• Fee bearer (bearer) is set according to your business model

Transaction verification

• Every transaction is verified server-side using the secret key before delivering value
• Verification uses the transRef (Credo reference), not only the callback parameters
• All transaction statuses are handled - not just 0 (successful)
• Failed and cancelled transactions are handled gracefully with clear user feedback
• Verification responses are logged for debugging and reconciliation

Webhooks

• Webhook URL is configured in the production dashboard under Settings → Webhooks
• Webhook endpoint is publicly accessible over HTTPS
• Endpoint responds with HTTP 200 immediately upon receiving a request
• X-Credo-Signature header is validated using SHA512(secretKey + businessCode)
• All relevant event types are handled: transaction.successful, transaction.failed, transaction.transaction.transfer.reverse, transaction.settlement.success
• Webhook events are processed asynchronously after returning the 200 response
• Your system handles duplicate webhook deliveries idempotently (use transRef + event as key)
• Webhook failures are monitored — Credo retries up to 5 times

Error handling

• API errors (4xx, 5xx) are caught and handled with user-friendly messages
• Validation errors from the API are parsed and displayed to the user
• Network timeouts are handled with appropriate retry logic
• Duplicate reference errors are handled (reuse the existing transaction instead)
• All errors are logged with enough context for debugging

Security

• All API communication uses HTTPS - never HTTP
• Secret keys are not committed to version control (check .gitignore)
• No API keys appear in frontend JavaScript bundles, logs, or error messages
• Input is validated and sanitized before sending to the API
• CORS is configured to restrict access to your domains only
• Rate limiting is in place to prevent abuse of your payment endpoints

Settlement & payouts

• Settlement bank account details are correct and verified
• Split settlement configuration is tested (if applicable)
• serviceCode or splitConfiguration rules are correct for production accounts
• Paused settlement dates (pauseSettlementDate) use future dates where intended
• Settlement amounts and fee deductions have been validated against test transactions

Testing & QA

• End-to-end payment flow has been tested in sandbox with test cards
• All payment channels you support have been individually tested
• Callback redirects work correctly for success, failure, and cancellation states
• Webhook delivery has been confirmed in the sandbox dashboard
• Edge cases are handled: expired sessions, double submissions, back-button navigation
• Load testing has been performed if expecting high transaction volumes

Monitoring & observability

• Transaction logs are captured with references, amounts, and statuses
• Alerts are set up for failed transactions or webhook delivery failures
• Dashboard notifications are enabled for key events
• A process exists for reviewing flagged/declined transactions (status 6 / 7)
• Settlement reports are being reconciled regularly

Customer experience

• Payment page loads quickly and works on mobile devices
• Clear error messages are shown when payments fail
• Customers receive confirmation (email, in-app, or receipt) after successful payment
• A support contact is visible if customers encounter issues
• Payment amounts and currency are displayed clearly before redirecting to checkout

---

Once you've checked everything above, you're ready to go live. Switch your API keys, update your base URL, and start processing real transactions.