Complete the final production-readiness checks before you move live funds through NadaPay.

⏱️

Time to integrate: Most teams can complete final go-live preparation in under 1 hour once sandbox validation, onboarding approval, and production credentials are ready.

Use this page to move from a working sandbox integration to a controlled production launch. It covers security, network requirements, funding readiness, operational checks, and launch coordination.

What this page covers

Use this checklist to confirm that your team is ready to:

• use production API credentials safely
• send requests from approved infrastructure
• validate live account and funding readiness
• monitor production traffic and failures
• launch with clear ownership across engineering, operations, and compliance

Prerequisites

Complete these steps before you start the go-live checklist:

1. Complete onboarding and required KYC/KYB approval.
2. Validate your core integration in sandbox.
3. Confirm which NadaPay flows you will enable first in production.
4. Prepare your production infrastructure, secret storage, and monitoring.

Go-live checklist

Follow these steps in order.

1. Confirm sandbox integration sign-off

Before you request or enable production access, confirm that your sandbox flow is complete end to end.

Your team should be able to demonstrate:

• successful authentication with x-api-key
• account retrieval
• beneficiary creation or update
• quote generation
• transaction execution handling
• failed or rejected outcome handling

Recommended evidence to keep internally:

• sample request and response logs
• sandbox transaction IDs
• screenshots or recordings of the end-to-end flow
• notes showing how your system handles errors and retries

2. Issue and secure production API credentials

Use separate production credentials for live traffic.

Store production API keys only in secure server-side systems such as:

• managed secrets platforms
• protected runtime environment variables
• restricted deployment configuration systems

Do not:

• commit keys to source control
• share keys in chat or tickets
• expose keys in browser or mobile clients
• reuse sandbox secrets in production

3. Configure network controls and IP allowlisting

Production requests should originate only from approved infrastructure.

Prepare:

• static outbound IP addresses for your production services
• a list of services or systems that will call NadaPay directly
• an internal owner for allowlist changes

According to the current production guidance, requests from non-whitelisted IPs return 403 Forbidden and trigger a security alert.

For launch readiness:

1. Confirm which services will call NadaPay.
2. Provide the static IPs for those services.
3. Test production connectivity from the approved infrastructure.
4. Remove outdated or temporary IPs after migration.

4. Complete compliance and operational review

Before you move live funds, confirm that your production organization is approved for the flows you plan to use.

Check these items:

• KYB or KYC approval is complete for the production organization
• beneficiary data collection meets your compliance requirements
• expected transaction volume aligns with your approved operating limits
• internal approvals are complete for launch, treasury operations, and support escalation

Use the verification endpoint as an operational check if your launch process depends on current approval state.

5. Fund your production accounts

Before you execute live transactions, confirm that the correct NadaPay account has sufficient balance in the required currency.

Recommended production checks:

1. Retrieve your available accounts.
2. Confirm the account ID you will transact from.
3. Confirm the available currency balance.
4. Top up the account if needed.
5. Recheck balances before your first live batch or launch window.

If you do not have sufficient funds in the target currency, your transaction flow may fail before completion.

6. Validate production-safe request handling

Before launch, confirm that your application handles production traffic safely.

At minimum, validate:

• authentication failures caused by missing or invalid x-api-key
• field validation errors
• insufficient balance conditions
• rate limit responses per API key
• transaction failures or rejected outcomes

Default rate limits are 100 requests per minute in sandbox and 1000 requests per minute in production, applied per API key.

Recommended safeguards:

• central request logging
• structured error handling by endpoint
• alerting for repeated failures
• backoff for retriable conditions
• separation between user-facing and batch processing traffic

⚠️

Needs confirmation: Error code catalog and retry guidance still need to be documented.

7. Prepare asynchronous transaction monitoring

If your production workflow depends on transaction status changes after execution, prepare your monitoring and reconciliation process before launch.

Your production operations should:

• poll for transaction status where needed
• log status changes and response payloads
• alert your team when transactions remain in a non-terminal state longer than expected
• retry internal processing safely when downstream systems fail
• keep user-facing status and internal operations views aligned

⚠️

Needs confirmation: Exact status polling guidance, reconciliation workflow, and timeout expectations are not yet documented.

8. Define production ownership and launch support

Assign named owners for:

• API integration and deployment
• treasury or liquidity operations
• compliance escalation
• incident response
• customer support or internal operations

Before launch day, confirm:

• who monitors the first live transactions
• where alerts are delivered
• who can pause traffic or stop a batch job
• how your team escalates issues to NadaPay

The current guidance recommends sharing your intended launch date and ensuring access to a priority support channel during the first 24 hours of live processing.

⚠️

Needs confirmation: Official support SLAs, escalation channels, and coverage hours are not yet defined here.

Recommended production architecture

Backend-only API access

Call NadaPay from server-side services only. Do not expose your x-api-key in frontend, mobile, or partner-managed client applications.

Mode separation

Keep these values separated in your internal configuration for sandbox and production mode:

• API keys
• monitoring dashboards
• alert routing

Auditability

Log these identifiers where available:

• internal request ID
• NadaPay transaction ID
• organization ID
• beneficiary ID
• account ID
• timestamp and initiating service

These records make incident review, reconciliation, and internal audit easier.

Production readiness checklist

Use this checklist before the final launch decision.

Troubleshooting

403 Forbidden in production

Check these items first:

• confirm the request is using the production API key
• confirm the request originates from an allowlisted IP
• confirm you are using the correct production API key and base URL

Authentication works in sandbox but fails in production

Confirm:

• the production key is active
• the production secret was deployed correctly
• sandbox configuration was not promoted accidentally

First live transaction fails

Check:

• source account balance
• beneficiary data completeness
• quote validity and transaction timing
• field-level validation errors in the request

Volume spikes trigger failures

Default rate limits are 100 requests per minute in sandbox and 1000 requests per minute in production.

Because rate limits are enforced per API key, review whether:

• too many workers share a single key
• retries are happening without backoff
• background jobs and user-triggered traffic are competing for the same capacity

Next steps