SDKs

Cette page liste tous les packages Wajub officiels et ce qu'il leur faut pour fonctionner. Choisissez le vôtre selon l'endroit où s'exécute votre code et le langage que vous écrivez déjà.

Où s'exécute votre code

Cette seule question détermine le package à choisir.

La plupart des intégrations utilisent deux packages : un SDK serveur pour créer le paiement et un package pour navigateur ou mobile afin de l'encaisser. Cette séparation ne relève pas du style, elle dépend de l'endroit où la clé secrète peut être utilisée.

SDKs serveur

Sept langages, qui couvrent chacun toute l'API : choisissez celui que vous écrivez déjà.

Si votre version est inférieure au minimum, appelez directement l'API REST. Elle utilise HTTPS et JSON. Chaque endpoint de ce site fournit un exemple brut.

Le même appel de sept façons

Créez un paiement, puis recevez un jeton pour le navigateur et une URL de redirection.

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 et C# fonctionnent de la même façon selon leurs propres conventions. Chacun dispose de sa page : Ruby, Java, C#.

Fonctionnalités de chaque SDK serveur

Le client est organisé par ressources : un objet par ressource de l'API.

Autour d'elles, chaque SDK serveur vous fournit :

• Votre propre Idempotency-Key sur tout appel de modification, quand vous en avez besoin.
• Une classe d'erreur par type d'échec pour distinguer l'authentification, la validation, la limite de requêtes et le transport avant même de lire le message.
• Des listes que vous parcourez d'une page à l'autre.
• Vérification de signature des webhooks pour sécuriser en un appel l'endpoint qui reçoit les événements.
• Une référence de compte Sync par requête pour les plateformes qui débitent au nom de leurs marchands.

Le nommage suit chaque langage : snake_case en Python et Ruby, camelCase ailleurs (méthodes PHP comprises, listRefunds). Le format d'échange reste en snake_case. Consultez les Conventions de nommage des SDKs.

Dans le navigateur

Ces packages affichent un checkout. Ils ne détiennent jamais de clé et ne peuvent ni rembourser, ni effectuer un payout, ni lister quoi que ce soit. Votre serveur crée d'abord la session.

Les quatre packages de framework nécessitent l'installation de @wajub/js à leurs côtés.

Toute la section possède sa propre arborescence : Wajub Components.

Dans une application mobile

Une interface de paiement native utilise une session créée par votre serveur. Le client choisit un opérateur, saisit un numéro et approuve depuis son téléphone sans quitter votre application.

iOS est un package Swift

Deux produits d'un même package Swift, ajoutés avec Swift Package Manager. WajubMobileUI contient l'interface de paiement SwiftUI et apporte WajubMobile avec lui. Utilisez WajubMobile seul si vous créez vous-même l'interface de paiement. Aucun des deux ne dépend de Stripe : pour les cartes Stripe, votre application fournit un CardCollector. Consultez iOS.

Ce que couvre chaque package

La couverture dépend de l'endroit où le code s'exécute, pas du langage : chaque SDK serveur couvre tous les produits.

Chaque SDK serveur propose également customers, identity, events, webhooks, webhookEndpoints et global.

Un label d'aperçu ou de bêta concerne le produit, jamais le SDK. La page du produit indique si shield ou tax est disponible pour votre compte.

Contraintes à connaître avant de choisir

Un autre point est à connaître. La liste des packages ne permet pas de le deviner.

Le chemin du module Go n'est pas celui qu'il semble être

Le chemin d'importation est github.com/wajubhq/wajub-go. L'organisation s'appelle wajubhq. github.com/wajub/wajub-go ne correspond à rien.

En ligne de commande

@wajub/cli est le seul package de cette page qui n'est pas destiné au code de production. Il transfère les webhooks vers votre machine, déclenche des événements de test et lit les ressources de votre API pendant le développement.

L'installation et toutes les commandes figurent dans les pages de la CLI.

Sans SDK

Aucun élément de cette page n'est obligatoire. La référence API documente chaque endpoint avec des exemples de requêtes et de réponses. Utilisez-la pour un langage sans package officiel, un environnement qui n'accepte pas de nouvelle dépendance ou si vous préférez voir directement les échanges.

Deux autres décisions à prendre

Choisir le package ne revient pas à choisir l'intégration. Il reste deux décisions distinctes, chacune présentée sur sa propre page.