SDKs & Libraries

Every official Wajub package, where it lives, and which one your stack needs.

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.

Where your code runs

That question decides the package, and nothing else does.

Your code runs	Reach for	Because
On your server	A server SDK	It holds the secret key, so it can do everything
In a browser	Wajub Components	It renders and confirms a checkout, nothing more
In a mobile app	A mobile SDK	It renders a native payment sheet
In a terminal	The CLI	Local webhook forwarding and test events
On WordPress	A plugin	No integration code at all
Anywhere else	The REST API	Every endpoint, documented for raw HTTP

One rule governs the whole list

The secret key stays on your server. Browsers and mobile apps receive a session token, scoped to a single payment, produced by a server SDK. No package on this page changes that, and the API answers 403 and emails the key's owner when a sk. key arrives from a browser. See Sessions and security.

Server SDKs

Seven languages, one surface. They are versioned together and released together, so the difference between them is syntax rather than capability.

Language	Package	Registry	Version	Runtime
Node.js	`@wajub/node`	npm	1.1.1	Node 18+
Python	`wajub`	PyPI	1.1.1	Python 3.10+
PHP	`wajub/wajub-php`	Packagist	2.0.0	PHP 8.4+
Go	`github.com/wajubhq/wajub-go`	Go modules	v1.1.1	Go 1.22+
Ruby	`wajub`	RubyGems	1.1.1	Ruby 3.1+
Java	`com.wajub:wajub-java`	Maven Central	1.1.1	Java 17+
C# and .NET	`Wajub`	NuGet	1.1.1	.NET 8+

The Python package on PyPI is currently empty

wajub 1.1.1 publishes only a py.typed marker. pip install wajub succeeds and import wajub raises ModuleNotFoundError, so the SDK cannot be used until a fixed build is released. Until then, call the REST API directly with httpx or requests. Every endpoint carries a Python 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.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…" \
-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.

Group	Resources
Money in	`payments`, `refunds`, `disputes`, `links`, `invoices`
Money out	`transfers`, `beneficiaries`, `balance`
People and accounts	`customers`, `accounts`, `identity`
Risk and compliance	`shield`, `tax`
Plumbing	`events`, `webhooks`, `webhookEndpoints`, `listen`, `global`

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, PHP and Ruby, camelCase elsewhere, 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.

Package	Framework	Version
`@wajub/js`	Vanilla, bundler or CDN	1.4.0
`@wajub/react`	React 18+, Next.js	1.4.0
`@wajub/vue`	Vue 3.3+, Nuxt	1.4.0
`@wajub/svelte`	Svelte, SvelteKit	1.4.0

The three 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.

Package	Platform	Version	Needs
`wajub_mobile`	Flutter	1.1.1	Dart 3.5+
`@wajub/react-native`	React Native	1.1.1	React Native 0.74+, `@stripe/stripe-react-native`
`com.wajub:wajub-mobile-core`	Android, Kotlin	1.1.0	Compose UI in `wajub-mobile-compose`

A payment sheet, not a merchant client

Mobile SDKs cover Payments and nothing else. Refunds, payouts, Billing, Sync, Shield and Tax stay on your server, where the secret key is. The shared architecture is on Mobile SDKs.

There is no Swift package for iOS

Three paths work on iOS today, in order of effort. React Native ships the full payment sheet. Flutter does the same if a cross platform rewrite is acceptable. Otherwise open the hosted checkout URL your server produced inside a WKWebView, which needs no SDK at all. A native Swift package is not on the public roadmap, so talk to support before committing engineering time.

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.

Package	Registry	Version	Runtime
`@wajub/cli`	npm, Homebrew, Scoop	1.4.0	Node 20+

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.