Choose your SDK

Three questions, one package, plus the constraints that rule options out.

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.

1. Where does the code run

It runs	Take	Because
On your server	A server SDK	It holds the secret key, so nothing is out of reach
In a browser	Wajub Components	It renders and confirms a checkout
In a mobile app	A mobile SDK	It renders a native payment sheet
On WordPress	The plugin	No integration code at all
Nowhere yet	Payment Links or Invoice	A payable link, no code and no package
Somewhere with no package	The REST API	Every SDK is a wrapper over it

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.

Already know your stack?

Jump straight there. Node.js, Python, PHP, Go, Ruby, Java, C#, JS, React, Vue, Svelte, Flutter, React Native, Android.

2. Does your runtime qualify

This is the question that eliminates options. Versions and registries are on SDKs and Libraries.

Server

Language	Package	Needs at least
Node.js	`@wajub/node`	Node 18
Python	`wajub`	Python 3.10, and `httpx`
PHP	`wajub/wajub-php`	PHP 8.4, and Guzzle 8.2
Go	`github.com/wajubhq/wajub-go`	Go 1.22
Ruby	`wajub`	Ruby 3.1, no runtime gems
Java	`com.wajub:wajub-java`	Java 17, and OkHttp
C# and .NET	`Wajub`	.NET 8

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

Browser

Package	Needs at least
`@wajub/js`	A browser that understands ES2020, and an ESM bundler or the CDN script
`@wajub/react`	React 18, React DOM 18
`@wajub/vue`	Vue 3.3
`@wajub/svelte`	Svelte 4 as declared, see the warning below

All four need @wajub/js installed beside them. It is a peer dependency, not a bundled one.

The Svelte package declares more than it was built for

peerDependencies says svelte: ">=4", but the published bundle registers itself as Svelte 5 and carries Svelte 5 client internals. On Svelte 5 it is what it claims. On Svelte 4, test it against your own build before you commit to it.

Mobile

Package	Platform	Needs at least
`wajub_mobile`	Flutter	Dart 3.5, and `flutter_stripe`
`@wajub/react-native`	React Native	React Native 0.74, React 18, `@stripe/stripe-react-native` and `@react-native-community/netinfo`
`com.wajub:wajub-mobile-core`	Kotlin, any JVM	Java 17, Kotlin 2.0
`com.wajub:wajub-mobile-compose`	Android	Android 7.0, API 24, and Jetpack Compose

Android ships as two artifacts, and you usually want both

wajub-mobile-core is a plain Kotlin and JVM library, no Android dependency, no manifest. It is the session client. wajub-mobile-compose is the Android archive that carries the Material 3 payment sheet and depends on the core. Take core alone only when you are building the payment interface yourself.

3. Does it cover what you need

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.

Product	Server SDKs	Browser	Mobile
Payments	`payments`, `refunds`, `disputes`, `links`	Checkout only	Payment sheet only
Billing	`invoices`	No	No
Transfers	`transfers`, `beneficiaries`, `balance`	No	No
Sync	`accounts`, plus a per request account reference	No	No
Shield	`shield`	No	No
Tax	`tax`	No	No

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

Browser and mobile packages are not merchant clients

They render a payment against a session your server already created. There is no refund, no payout, no invoice and no account listing in them, and there will not be: those calls need the secret key, and the secret key never leaves your server. See Sessions and security.

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

Four things eliminate an option outright, and none of them is obvious from a package listing.

The Python package on PyPI is empty

wajub 1.1.1 ships only a py.typed marker. pip install wajub succeeds, import wajub raises ModuleNotFoundError. Until a fixed build is published, a Python backend talks to the REST API directly with httpx or requests.

There is no Swift package

Nothing native for iOS, and nothing on the public roadmap. Three paths work today.

Path	Effort	What you get
React Native	Lowest, if the app is already React Native	The full payment sheet
Flutter	A cross platform rewrite	The same sheet
Hosted checkout in a `WKWebView`	Lowest overall	The whole Wajub page, no dependency

If iOS is a hard requirement for a native experience, talk to support before you plan the work.

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.

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.

Decision	Where
Hosted page, inline embed, overlay, or your own fields	Choosing your payments integration
How API field names land in your language	SDK naming conventions