SDKs et bibliothèques

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.

Où s'exécute votre code

Cette seule question détermine le package à choisir.

SDKs serveur

Sept langages pour une seule interface. Ils sont versionnés et publiés ensemble. Seule leur syntaxe diffère, pas leurs possibilités.

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.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…" \
-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, PHP et Ruby, camelCase ailleurs. 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 trois 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.

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.