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

⚠️

Needs confirmation: Whether NadaPay requires a formal certification, live demo, or recorded walkthrough before production enablement is not yet fully documented.

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

⚠️

Needs confirmation: The docs do not yet define whether multiple production keys, scoped keys, or read-only keys are supported.

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 environments 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 environment.
4. Remove outdated or temporary IPs after migration.

⚠️

Needs confirmation: The exact process for submitting IP addresses, expected turnaround time, and emergency allowlist update path are not yet documented.

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.

⚠️

Needs confirmation: Exact production approval states, transaction tier limits, and beneficiary metadata requirements are not yet fully documented here.

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.

⚠️

Needs confirmation: The exact production funding workflow, supported funding rails, settlement timing, and treasury portal steps are not yet documented in detail.

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

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: Exact rate limit thresholds, error code catalog, and retry guidance still need to be documented.

7. Prepare webhook and event operations

If your production workflow depends on asynchronous transaction updates, prepare your webhook infrastructure before launch.

Your webhook service should:

• receive HTTPS requests reliably
• log incoming event payloads
• return a successful acknowledgment promptly
• retry internal processing safely when downstream systems fail
• alert your team when delivery handling degrades

⚠️

Needs confirmation: Exact webhook event types, signature verification method, retry schedule, 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.

Environment separation

Keep these values separate for sandbox and production:

• API keys
• base URLs
• webhook endpoints
• 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 calling the correct production 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

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