Introduction

Wajub is a payment orchestration platform designed for Africa. Instead of integrating each Mobile Money operator, bank or aggregator separately, you integrate a single API. Wajub then routes each transaction to the best available provider, handles failures and exposes standardized webhooks.

Before you start

To follow any example on this site you need three things.

1. A Wajub account. Create one for free at dashboard.wajub.com.
2. An API key. Once logged in, open Settings → Developer → API Keys and create one.
3. An HTTP client, curl, or a server SDK (Node.js, Python, PHP, Go, Ruby, Java, C#).

A new account holds no key at all. You create the ones you need, one at a time, in the environment the Dashboard is showing. Production keys can only be created once your account is verified.

See Setup your account for a step-by-step walkthrough of the Dashboard.

What you can build

• Collect payments via Mobile Money (MTN MoMo, Orange Money, Wave, Airtel), card and bank transfer.
• Pay out funds to Mobile Money wallets via the Transfers API or manage Beneficiaries.
• Embed checkout directly in your app with Wajub Components, React, Vue, Svelte or vanilla JS.
• Orchestrate your providers intelligently with routing and fallback (Orchestration).

How the API works

The Wajub API is organized around REST. It uses predictable URLs, accepts JSON-encoded request bodies, returns JSON responses and relies on standard HTTP codes.

All requests go through a single base URL:

https://api.wajub.com

Your first call

A payment starts with one request. You send the amount, the currency, who is paying, and the page you want that person sent back to once they are done. Wajub creates the payment, keeps it pending and answers with a hosted page where the customer picks their operator and confirms. Nobody is charged at this point, and no operator has been contacted yet.

Describe the payer inside the customer object rather than at the root of the request. The API also accepts a top-level email, and both end up on the same customer record, but the object is the structure that grows with you: it carries name, phone, address and metadata as well, and its values take precedence over their root twins. The callback is where Wajub returns the customer once the payment page is done with them.

Run it from your server or your terminal with your private sandbox key (sk_test.…). Never put that key in a browser or a mobile app. Wajub also issues a public key (pk_test.…), meant for creating a payment from the browser. See Key Concepts → API keys for the full breakdown.

curl https://api.wajub.com/payments \
  -H "Authorization: sk_test.xxxxxxxxxxxxxxxx…" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 25000,
    "currency": "XAF",
    "customer": { "email": "[email protected]" },
    "description": "Order #4172",
    "callback": "https://shop.example.com/order/complete"
  }'

Wajub answers 201 Created. The payment now exists on your account, it carries an id you will use everywhere else, and it holds the two values that drive the rest of your integration:

Three fields of that response matter right now:

• authorization_url is the hosted payment page for this payment and nothing else. Redirect your customer to it. This is the simplest way to integrate Wajub, and the one we recommend.
• authorization_token is the session token embedded in that URL. It is scoped to this single payment and safe to hand to a browser, which is what the Components use when you prefer to keep the customer on your own page.
• transaction.status starts at pending. It becomes succeeded only once the customer has confirmed on their phone, which happens well after this call has returned.

"Payment" vs "transaction"

You just saw both words in the same response, and they name the same object. "Payment" is the business concept, so the endpoint is POST /payments. "Transaction" is what the API serializes, so the response nests it under "transaction" and prefixes the id with trx_. The two terms are interchangeable throughout this documentation. The full explanation lives in Key Concepts.

What happens next

Opening authorization_url in your browser puts you on the payment page, where sandbox phone numbers let you simulate a success, a refusal or a timeout. Your server then confirms the outcome with GET /payments/{id} before shipping anything, because the browser return alone can be forged or simply never happen. The Quickstart walks through both steps with the test numbers.

What's next?

Just getting started

• Quickstart: process a first payment in 5 minutes.
• SDK Quickstart: install the SDK for your language (Node.js, Python, PHP, Go).
• Key Concepts: payment lifecycle, sandbox vs live, session tokens.
• Environments & API keys: test vs production.

Ready to build

• Guides & Tutorials: step-by-step integrations for every use case.
• Payment methods & channels: full country × operator coverage.
• API Reference: every endpoint with request/response examples.

Going deeper

• Best Practices: idempotency, error handling, security.
• Going Live: production checklist and KYC.
• All SDKs & Libraries: Node.js, Python, PHP, Go, mobile, and browser SDKs.