SDKs

Il existe une seule API Wajub. Chaque package de cette page est une enveloppe légère qui respecte les conventions de son langage. Aucun ne fait donc plus que l'API REST. Ces enveloppes gèrent pour vous l'authentification, les nouvelles tentatives, l'idempotence, les erreurs typées et la pagination que vous devriez sinon réécrire dans chaque projet.

La majeure partie de la décision s'impose d'elle-même. Le package dépend de l'endroit où votre code s'exécute et le langage de celui que vous utilisez déjà. Il vous reste à vérifier la compatibilité de votre environnement d'exécution et la couverture de vos besoins par le package.

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 pour une seule interface. Ils exposent les mêmes ressources. Seule leur syntaxe diffère, pas leurs possibilités. PHP est en 2.0.1, Node.js et C# en 2.0.0, Ruby en 1.3.0, les autres en 1.2.1.

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. Tous les SDKs serveur partagent cette structure.

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. Chaque ressource de l'API possède un objet dont le nom reste identique partout.

Ils fournissent aussi les comportements que vous devriez autrement recréer dans chaque projet.

• Une Idempotency-Key est générée pour chaque appel de modification, mais vous pouvez fournir la vôtre.
• Nouvelles tentatives sur 429 et 5xx, avec attente exponentielle.
• 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.
• Pagination par pages avec un itérateur qui récupère la page suivante pour vous.
• 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, en version 1.8.0 ou ultérieure pour @wajub/angular. Il s'agit d'une dépendance homologue, non intégrée.

Les quatre packages de framework enveloppent @wajub/js, lui-même un petit chargeur qui récupère l'environnement d'exécution du checkout depuis https://js.wajub.com. 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, le client de l'API et la logique du checkout, qui ne dépend que de Foundation. Utilisez WajubMobile seul si vous créez vous-même l'interface de paiement. Aucun des deux ne dépend de Stripe : une carte Stripe passe par un CardCollector que votre application écrit. Consultez iOS.

Ce que couvre chaque package

La couverture dépend de l'endroit où le code s'exécute, pas du langage. Les sept SDKs serveur exposent les dix-huit mêmes ressources sous les mêmes noms. Les fonctionnalités ne justifient donc pas d'en privilégier un.

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

Un label d'aperçu ou de bêta concerne le produit, jamais le SDK. Les clients ne bloquent aucune fonctionnalité. shield et tax sont donc accessibles dès maintenant depuis chaque langage. La page du produit indique s'il est disponible pour votre compte.

Contraintes à connaître avant de choisir

Deux autres points sont à connaître. La liste des packages ne permet pas de les 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.

Le groupe Android est nommé com.wajub

Les deux artefacts Android sont publiés sous com.wajub, pas co.wajub. Une coordonnée Gradle qui utilise le mauvais groupe ne peut tout simplement pas être résolue.

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. Chaque SDK ajoute quelques milliers de lignes au-dessus de HTTPS et JSON. 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.