Going Live

All API requests must be made over HTTPS to: https://app.kdadatasub.name.ng

When to Go Live

You are ready to switch to a Live API Key once you have completed and verified the following in the sandbox:

All purchase flows (data, airtime, tv, electricity, exam, data-card, recharge-card) return SUCCESS with the expected fields.
Your server correctly handles PENDING statuses and never retries with a new idempotencyKey while a purchase is unresolved.
You handle the full error catalog — including CONFLICT, TRANSACTION_FAILED, and rate-limit responses — without crashing.
You have subscribed to Webhooks — the Purchase category — and reconciled at least one PURCHASE_SUCCESS / PURCHASE_FAILED payload against your transaction history.

Never switch to a live key while any of the above are still being tested. Live transactions deduct real funds from your wallet and cannot be reversed through the sandbox simulator.

Sandbox vs. Live

Prop

Type

Getting a Live Key

Sign in to your KDA dashboard and open Settings → Dev Console.
Generate a Live API Key with the scope your integration needs — services for purchases, profile for account endpoints, or a combination.
Fund your wallet with enough balance to cover expected transaction volume. Live purchases are settled against your wallet balance in real time.
Store the key in your backend secrets manager — never in client-side code, mobile apps, or public repositories.

Cutover Checklist

Verify Your Test Key

Call the /api/services/test endpoint with your test key and confirm the response reports "environment": "TEST" before switching anything.

Deploy Your Live Key

Update your server environment to use the kds_live_* key and redeploy. Keep the test key configured as a fallback for staging environments.

Confirm the Environment

Call /api/services/test again — the response must now report "environment": "LIVE" and your account details.

Run a Small Live Purchase

Execute a low-value purchase (e.g. a cheap data or airtime plan) and confirm:

The wallet balance debited by the exact amount returned.
The transaction appears in Transaction History with status: "SUCCESS".
Your webhook endpoint (subscribed to the Purchase category) received PURCHASE_SUCCESS with the matching transactionId and idempotencyKey.

Monitor and Scale

Gradually increase volume while watching for PENDING statuses, provider errors, and webhook delivery failures. Reconcile daily against the transactions endpoint.

Guardrails in Production

Never expose your live key in client-side code (frontend, mobile apps).
Always send an idempotencyKey (UUID v4) on every purchase request to prevent double charges on retries.
Never retry a PENDING transaction with a new key — wait for the webhook or query transaction history instead.
Rotate keys periodically from the Dev Console and invalidate any key that may have leaked.
Fund your wallet proactively — insufficient balance causes purchases to fail with 412 - PRECONDITION_FAILED.