SDKs

There is one Wajub API. Every package on this page is a thin wrapper over it, written in the idioms of its language, so nothing here does something the REST API cannot. What the wrappers buy you is authentication, retries, idempotency, typed errors and pagination that you would otherwise write once per project.

Most of this decision is made for you. The package follows from where your code runs, and the language follows from what you already write. What is left is checking that your runtime qualifies and that the package covers what you need.

Where your code runs

That question decides the package, and nothing else does.

Most integrations use two: a server SDK to create the payment, and a browser or mobile package to collect it. That split is not a style choice, it is where the secret key is allowed to be.

Server SDKs

Seven languages, one surface. They expose the same resources, so the difference between them is syntax rather than capability. PHP is at 2.0.1, Node.js and C# at 2.0.0, Ruby at 1.3.0, the others at 1.2.1.

Below the floor, call the REST API directly. It is HTTPS and JSON, and every endpoint on this site carries a raw example.

The same call, seven ways

Create a payment, get back a token for the browser and a URL for a redirect. This is the shape every server SDK shares.

curl https://api.wajub.com/payments \
-H "Authorization: sk_test.xxxxxxxxxxxxxxxx…" \
-H "Content-Type: application/json" \
-d '{"amount": 15000, "currency": "XAF", "customer": {"email": "buyer@example.com"}}'

Ruby, Java and C# read the same way in their own idiom. Each has its own page: Ruby, Java, C#.

What every server SDK gives you

The client is resource oriented. One object per API resource, the same names everywhere.

Around them, the behaviour you would otherwise rebuild in every project.

• An Idempotency-Key is generated for every mutating call, and you can pass your own.
• Retries on 429 and 5xx, with exponential backoff.
• One error class per failure kind, so authentication, validation, rate limiting and transport failures are told apart before you read a message.
• Page based pagination with an iterator that fetches the next page for you.
• Webhook signature verification, so the endpoint that receives events is one call away from being safe.
• A Sync account reference per request, for platforms charging on behalf of their merchants.

Naming follows each language, snake_case in Python and Ruby, camelCase elsewhere (PHP methods included, listRefunds), while the wire format stays snake_case. The mapping is on SDK naming conventions.

In the browser

These render a checkout. They never hold a key, and they cannot refund, pay out or list anything. Your server creates the session first.

The four framework packages need @wajub/js installed beside them, 1.8.0 or later for @wajub/angular. It is a peer dependency, not a bundled one.

The four framework packages are wrappers around @wajub/js, which is itself a small loader that fetches the checkout runtime from https://js.wajub.com. The whole section has its own tree: Wajub Components.

In a mobile app

A native payment sheet against a session your server created. The customer picks an operator, enters a number, and approves from their phone without leaving your app.

iOS ships as a Swift package

Two products of one Swift package, added with Swift Package Manager. WajubMobileUI carries the SwiftUI payment sheet and brings WajubMobile with it, the Foundation-only API client and checkout logic. Take WajubMobile alone when you build the payment interface yourself. Neither depends on Stripe: a Stripe card goes through a CardCollector your app writes. See iOS.

What each package covers

Coverage follows from where the code runs, not from the language. All seven server SDKs expose the same eighteen resources under the same names, so there is no feature reason to prefer one.

Alongside those sit customers, identity, events, webhooks, webhookEndpoints, listen and global, which every server SDK also carries.

A preview or beta label belongs to the product, never to the SDK. The clients do not gate anything, so shield and tax are callable from every language today. Whether the product behind them is ready for your account is on its own page.

Constraints worth knowing before you commit

Two more things are worth knowing, and neither is obvious from a package listing.

The Go module path is not what it looks like

The import path is github.com/wajubhq/wajub-go. The organisation is wajubhq, and github.com/wajub/wajub-go resolves to nothing.

The Android group is com.wajub

Both Android artifacts are published under com.wajub, not co.wajub. A Gradle coordinate on the wrong group simply fails to resolve.

On the command line

@wajub/cli is the only package here that is not for production code. It forwards webhooks to your machine, triggers test events, and reads your API resources while you build.

Installation and every command are on the CLI pages.

Without an SDK

Nothing on this page is required. Each SDK is a few thousand lines over HTTPS and JSON, and the API reference documents every endpoint with request and response examples. That is the right path for a language with no official package, for an environment you cannot add a dependency to, and for anyone who prefers to see the wire.

Two more things to decide

Picking the package is not the same as picking the integration. Two separate choices remain, and both have their own page.