Get started

Create your account

Sign up at new.app.kwiknkap.com with your phone number and email, then create your business profile: name, category, and the phone number money settles to.

You can build immediately. Sandbox works the moment the account exists — verification is not a gate on development, only on live money.

Start identity and business verification now anyway, because it takes days rather than minutes and it is what unlocks kn_sk_live_ keys. Doing it in parallel with your integration means you are not waiting on it at the end.

✅ You should now see the dashboard, with a Developers section in the sidebar.

Get a sandbox API key

In Developers → API keys, create a key. Choose the scopes it needs and nothing more — for a checkout server that is payments:write and payments:read, which is enough to take money and read back status, and not enough to touch invoices or send anything. See Scopes.

The key is shown once. Put it in your server's environment straight away:

Code
KWIKNKAP_API_KEY=kn_sk_test_...

Your key's prefix is the environment. kn_sk_test_ reaches sandbox; kn_sk_live_ reaches live and moves real money. There is no environment header to get wrong — see Environments and API keys.

✅ You should now see a key beginning kn_sk_test_, stored somewhere your server can read and your repository cannot.

Collect your first payment

Charge a wallet. The Idempotency-Key means a network retry cannot charge twice — why that matters.

Code
curl -X POST https://new.api.kwiknkap.com/v1/payments \
  -H "X-API-Key: $KWIKNKAP_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 5000,
    "phone_number": "237670000001",
    "payment_method": "mobile_money"
  }'

Code
{
  "id": "knpay_test_9f2c41a7b8e04d6fa1c3e58b7d92f014",
  "status": "PENDING",
  "amount": 5000,
  "currency": "XAF",
  "payment_method": "mobile_money",
  "environment": "SANDBOX"
}

PENDING is the correct answer, and it is not "paid". The customer has been prompted on their phone and has not decided yet. Read How a payment works before you write the code that acts on this — it is the single most expensive misunderstanding in this API.

✅ You should now see a 201 with status: PENDING and an id beginning knpay_test_.

Find out what happened

Poll while you are developing:

Code
curl https://new.api.kwiknkap.com/v1/payments/knpay_test_9f2c41a7b8e04d6fa1c3e58b7d92f014/status \
  -H "X-API-Key: $KWIKNKAP_API_KEY"

In production, take the outcome from a webhook instead: it arrives the moment the payment resolves, is signed so you can trust it, and is retried for three days if your endpoint is down.

A FAILED payment carries a failure_code you can act on. insufficient_funds is worth retrying after the customer tops up; customer_account_issue is not.

✅ You should now see the payment settle to SUCCESS or FAILED, with a failure code if it failed.

Go live

Before switching the prefix:

• Verification approved — no kn_sk_live_ key exists until it is.
• You fulfil on the transition into SUCCESS, never on seeing it, so a duplicate webhook cannot ship twice. How.
• Every create call sends an Idempotency-Key.
• Your webhook endpoint verifies signatures and answers 2xx in under a few seconds.
• You have triggered a real failure in sandbox and shown your customer something useful. Testing.
• Live keys are scoped to what that consumer actually does, and are not in your repository.

Then mint a kn_sk_live_ key, swap the environment variable, and deploy. Nothing else changes: same URL, same payloads, same codes.