Setup your account

Every call to the Wajub API is authenticated by a key, and a key belongs to one account and one environment. This page takes you from no account at all to an SDK that authenticates, which is the state the Quickstart assumes you are already in.

1. Create your account

Sign up at dashboard.wajub.com with your name, email and a password, then confirm the email we send you. Nothing is payable at this stage, a new account lands on the free Pay as you go plan.

Your user account comes first and your business second. Right after confirming your email, the Dashboard asks you to create your first merchant account, on a screen titled Tell us about your Business:

You are the owner of that account. The Dashboard stays on this screen until it exists, and you can create other merchant accounts later from the same user.

Your team is created in sandbox, and it stays there until your business verification is approved. Nothing you do now can move real money, which is the point: build and break things freely before activation opens production.

The Dashboard home shows a setup checklist tailored to what you said you were building. It tracks the same milestones this page covers, so you can follow either one.

2. Select the environment before you mint a key

This is the step people skip. A key is minted for whichever environment the Dashboard is currently showing, and that choice is stored per user and per team. Flip the environment switch to sandbox or to live first, then create the key. Create it in the wrong environment and it will authenticate fine while returning data from a database you did not mean to touch.

Live stays unavailable until your account is verified, so until then every key you create is a _test key whatever you do.

Switching environment is itself a permission. The account owner can always do it, other members need manage_settings, which only the Admin role carries by default, and a member with the Sandbox role can never switch to live.

3. Create your first API key

Open Settings → Developer → API Keys, at /settings/developer/keys, and create a key. You pick the type, and the prefix follows from that choice and from the environment you selected in step 2.

Start with a private key. A restricted key is worth the extra step once you know which endpoints you actually call, and Environments & API keys covers the scopes, the IP allow-list and the expiry date you can attach to any of them.

If you have the CLI installed, wajub login does this for you: it pairs the terminal with your account through the browser and provisions a key for the environment you choose, then stores it in a local profile. That key expires after 90 days, and wajub login gives you a new one.

4. Put the key in your environment

Keys belong in the environment, never in the code and never in the repository. Create a .env file at the root of your project and keep it out of git.

WAJUB_API_KEY=sk_test.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i……
WAJUB_WEBHOOK_SECRET=whsec_test_4f8c2b91d7e6a0f35c1dB7nY4hC6dF9j

WAJUB_API_KEY is the name every SDK recognises, so use it rather than inventing your own. WAJUB_WEBHOOK_SECRET is the signing secret of a webhook endpoint, a different credential entirely, and step 6 is where you get one.

5. Point the SDK at the key

Two of the SDKs read WAJUB_API_KEY from the environment on their own. Python and Go construct a working client from an empty configuration, so the snippets below pass nothing.

Node and PHP do not read the environment, they raise on an empty configuration, so you hand them the value yourself. Node accepts apiKey or its alias secretKey, they are the same field.

import { Wajub } from '@wajub/node';

const wajub = new Wajub({ apiKey: process.env.WAJUB_API_KEY });

Whichever SDK you use, all four read WAJUB_WEBHOOK_SECRET on their own for signature verification, so once that variable is set you never pass the secret explicitly.

6. Register a webhook endpoint

A payment confirms asynchronously, so your server learns the outcome from a webhook rather than from the response to the call that created it. Register the endpoint now, while you are in the Dashboard, so the Quickstart has somewhere to deliver to.

Open Konsole → Webhooks → Endpoints, add your URL, and copy the signing secret shown on the endpoint. It looks like whsec_test_ followed by 32 characters in sandbox, and whsec_ followed by 32 characters in production.

That secret is per endpoint and per environment. Registering the same URL again in live gives you a different secret, which is why going to production means copying a new one rather than reusing what you have. Use it to verify every incoming signature before you trust a payload.

7. Roll a key that leaked

Rolling replaces the value in place. The name, the scopes and the IP allow-list survive, the old value stops authenticating the moment you confirm, and there is no grace window where both work. So have the new value ready to deploy before you click, or you take an outage between the roll and the release.

Because it is destructive, rolling asks you to re-enter your password if you have not confirmed it in the last 30 minutes. Deleting a key asks the same.

8. Who on your team can do this

API keys are visible only to the account owner and to members holding the manage_api_keys permission, which the Admin, Developer and Sandbox roles carry. If the Developer section is missing from your Settings, ask an admin to change your role rather than hunting for the page. Team and security lists what each role can do.

9. When production opens

Verified accounts get live keys the same way, by switching the environment and creating a key. Live keys are separate objects, a sandbox key is never promoted. Plan on swapping the key, the webhook URL and its new signing secret together, and walk the Going Live checklist before you do.