SDKs

This page lists every official Wajub package and what it needs to run. Pick yours by where your code runs and the language you already write.

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, each covering the whole API, so pick the one you already write.

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.

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.

Around them, each server SDK gives you:

• Your own Idempotency-Key on any call that changes something, when you need one.
• One error class per failure kind, so authentication, validation, rate limiting and transport failures are told apart before you read a message.
• Lists you can iterate across pages.
• 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.

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. Take WajubMobile alone when you build the payment interface yourself. Neither depends on Stripe: for Stripe cards, your app provides a CardCollector. See iOS.

What each package covers

Coverage follows from where the code runs, not from the language: every server SDK covers every product.

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

A preview or beta label belongs to the product, never to the SDK. Whether shield or tax is ready for your account is on the product's own page.

Constraints worth knowing before you commit

One more thing is worth knowing, and it is not 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.

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