SDKs mobiles

Une architecture, trois packages et une interface de paiement native sans WebView.

Les trois SDKs mobiles reposent sur la même conception dans trois langages. Votre serveur crée le paiement et transmet un authorization_token à l'application. Celle-ci crée une session à partir du jeton et affiche une interface native. Le payeur ne quitte jamais votre application.

Ce parcours n'utilise aucune WebView, c'est tout son intérêt. Les champs Mobile Money sont natifs et les champs de carte utilisent les composants natifs de Stripe. Seule une vérification 3DS ou une redirection bancaire ouvre le navigateur du système.

Les trois packages

Plateforme	Package	Registre	Version
Flutter	`wajub_mobile`	pub.dev	1.1.1
React Native	`@wajub/react-native`	npm	1.1.1
Android	`com.wajub:wajub-mobile-core`	Maven Central	1.1.0
Android	`com.wajub:wajub-mobile-compose`	Maven Central	1.1.0

Il n'existe aucun package Swift

Wajub ne propose aucun SDK iOS natif. Une application Swift accède à Wajub grâce au checkout hébergé dans un SFSafariViewController, ou avec Flutter ou React Native. Consultez Choisir votre SDK pour comparer ces possibilités.

Le flux en une fois

Les trois SDKs suivent ces cinq étapes. Vous devez uniquement concevoir celle du milieu.

Lieu d'exécution de chaque partie

Your server                          Your app
───────────                          ────────
POST /payments with sk.
  returns authorization_token  ──▶   createSession(token)
                                       │
                                       ├─ loads the session and its channels
                                       ├─ shows the sheet you chose
                                       └─ processes the payment natively
                                           │
webhook payment.succeeded     ◀──────────┘
  fulfils the order

Le jeton est le seul identifiant détenu par l'application. Il est limité à un paiement, expire et ne permet pas de lister, de rembourser ou de lire quoi que ce soit d'autre sur votre compte. Votre clé secrète reste sur votre serveur.

Endpoints réellement utilisés par la session

Le SDK appelle api.wajub.com/pay/* avec Authorization: Bearer {token}. La page de checkout hébergé utilise les mêmes endpoints. L'interface mobile se comporte donc de la même façon et prend en charge les mêmes opérateurs.

Endpoint	Utilisation par le SDK
`GET /pay/session`	Montant, devise, image de marque et canaux disponibles
`GET /pay/sdk-config`	Paramètres du prestataire par canal, dont la clé publique Stripe
`POST /pay/process`	Envoie le paiement sur le canal choisi
`GET /pay/status`	Interroge le résultat lorsque le temps réel est indisponible
`POST /pay/cancel`	Abandonne la session et renvoie une URL de redirection

Process applique une limite de requêtes plus stricte

POST /pay/process autorise dix tentatives toutes les cinq minutes par jeton et par adresse. Cela permet au payeur de corriger un mauvais code PIN sans permettre une attaque par force brute. Ne placez pas cet appel dans une boucle de nouvelles tentatives.

Choisir l'interface

Chaque SDK propose deux niveaux. L'interface de paiement est la solution rapide. Utilisez les méthodes de session si le paiement doit s'intégrer à votre propre design.

Votre objectif	Solution
Un paiement fonctionnel dès maintenant	L'interface de paiement fournie
Vos propres écrans et votre image de marque	Les méthodes de session, `payMobileMoney` et `payCard`
Afficher le montant avant le paiement	`loadSession()`, puis l'affichage de votre choix
Un statut en direct pendant la confirmation du payeur	`watchStatus()`

Temps réel ou polling

La session contient un bloc echo lorsque le temps réel est activé sur le compte. S'il est présent, le SDK s'abonne avec Pusher et reçoit immédiatement le résultat. Sinon, il se replie sur un polling de GET /pay/status toutes les cinq secondes. Dans les deux cas, votre code appelle watchStatus() sans avoir à choisir.

Le webhook reste responsable de la livraison de la commande

Une confirmation Mobile Money peut arriver après la fermeture de l'application par le payeur. Le téléphone peut aussi perdre le réseau pendant l'approbation. Utilisez le résultat de l'interface pour choisir l'écran à afficher et le webhook pour livrer les biens.

Montants et erreurs sont également partagés

Les montants utilisent partout l'unité principale. Ainsi, 25000 en XAF correspond à vingt-cinq mille francs. Le type d'erreur est la même union de cinq possibilités dans les trois SDKs.

Type d'erreur	Signification
`authenticationError`	Le jeton a expiré, a déjà été utilisé ou est inconnu
`invalidRequestError`	Le canal a refusé un champ, identifié par `param`
`paymentError`	Le prestataire a refusé le paiement, `declineCode` indique la raison
`rateLimitError`	Trop de tentatives, `retryAfterSeconds` indique le délai d'attente
`apiError`	Erreur côté Wajub ou problème réseau

Chaque erreur contient retryable, qui détermine s'il faut proposer une nouvelle tentative au payeur.

Choisir votre plateforme

Pages associées