SDKs mobiles

Les SDKs mobiles de Wajub vous permettent d'encaisser des paiements Mobile Money, par carte et par portefeuille dans votre application, avec une interface de paiement prête à l'emploi. Choisissez ci-dessous le package de votre plateforme.

Choisir votre plateforme

L'interface propose le Mobile Money, la carte et les portefeuilles en un geste. Les autres moyens de paiement, comme le virement bancaire ou la crypto, n'y sont pas proposés.

Le parcours d'un paiement

Your server                            Your app
───────────                            ────────
POST /payments with sk.
  returns authorization_token   ──▶    present({ sessionToken })
                                         │
                                         ├─ the payer picks a method and pays
                                         ├─ approval, confirmation step or payment page
                                         └─ the sheet waits for the outcome
                                             │
                                         complete · processing · failed · cancelled
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.

États

Chaque état est un écran de l'interface, et votre callback onStateChange reçoit son nom.

SUCCESS, EXPIRED et CANCELLED sont définitifs. Un paiement déjà payé à l'ouverture de l'interface affiche l'écran de succès, et un paiement terminé affiche un avis et signale une erreur de chargement.

Résultats

L'appel qui présente l'interface se résout une seule fois, à sa fermeture, avec l'un de quatre résultats.

L'appel ne reste jamais en suspens. Quand l'écran qui a présenté l'interface disparaît, il se résout en cancelled avant tout paiement, en processing dès qu'un paiement a commencé et en complete après un succès, et il n'annule pas le paiement. Présenter une deuxième interface pendant qu'une autre est ouverte échoue avec sheet_already_presented. Si le système tue votre application, rien ne se résout : au lancement suivant, lisez l'issue sur votre serveur.

Annuler et fermer

Le payeur ferme l'interface avec son bouton de fermeture ou d'un balayage.

Un paiement annulé l'est pour de bon, et Wajub envoie le webhook payment.cancelled. Avec cancelOnDismiss: false, fermer avant de payer laisse le paiement ouvert : vous pouvez présenter l'interface à nouveau avec le même jeton.

L'interface n'affiche jamais un échec dont elle n'est pas sûre : elle affiche « Paiement en cours » et continue d'attendre. Fermée à ce moment, elle se résout en processing.

Mobile Money

Un seul formulaire couvre tous les opérateurs. Le payeur choisit le pays et l'opérateur et saisit le numéro, mis en forme pendant la saisie. Le préfixe du numéro présélectionne son opérateur, et un numéro qui appartient à un autre opérateur est signalé avant tout envoi. Après Payer, l'interface demande au payeur de valider le paiement sur son téléphone, ou de composer un code, et attend l'issue.

Certains opérateurs, comme Orange Money au Burkina Faso, n'acceptent un paiement qu'avec un code que le payeur génère d'abord dans le menu de l'opérateur. Sur Flutter, React Native et Android, le formulaire le signale quand Wajub le sait à l'avance ; dans tous les cas, après Payer, l'interface montre comment obtenir le code, le code à composer et le montant exact à saisir, puis prend le code. Un code que l'opérateur refuse peut être saisi de nouveau, avec les essais restants quand ils sont connus ; après trois refus, le payeur revient au formulaire pour payer autrement.

Partout où l'interface affiche un montant, sur Payer et sur chaque écran, c'est ce que paie le payeur : le montant du paiement, plus les frais Wajub quand le payeur les supporte (bearer: customer). Sur Flutter, React Native et Android, il suit le moyen ou l'opérateur que le payeur choisit.

Cartes

Selon le paiement, le payeur paie par carte à l'un de ces trois endroits.

• Le formulaire de carte de Stripe, dans l'interface. Intégré aux SDKs Flutter et Android. React Native a besoin du package facultatif @stripe/stripe-react-native, et sur iOS votre application fournit un CardCollector construit avec le SDK de Stripe. Chaque page de plateforme indique quoi ajouter.
• Une page sécurisée du prestataire de paiement, ouverte dans le navigateur. Donnez à returnUrl un lien universel ou un lien d'application https vers votre application pour y ramener le payeur. Sans lui, le payeur revient dans votre application de lui-même, et Continuer le paiement rouvre la page.
• Le formulaire de carte de test de Wajub, en sandbox.

En live, le numéro de carte n'est saisi que dans le formulaire de Stripe ou sur la page du prestataire.

Étapes de confirmation

Certains paiements par carte demandent une information de plus au payeur après Payer. Chaque étape a son propre écran.

Une mauvaise réponse garde l'écran et affiche les tentatives restantes. Une étape qui expire ou épuise ses tentatives se termine sur l'écran d'échec.

Apparence

L'option appearance règle l'aspect de l'interface. Ses clés, préréglages et variables sont décrits dans Apparence.

• Mode de couleur. light, dark ou auto, qui suit le téléphone.
• Préréglages. stripe, night, flat et none.
• Le thème de votre application. inherit: true reprend les couleurs de votre application ; chaque page de plateforme indique ce qu'il lit.
• Branding du marchand. Ce que vous laissez vide vient du branding du marchand dans le Dashboard : logo, nom commercial et couleurs. Un marchand en marque blanche masque « Sécurisé par Wajub ».
• Polices. Une fontFamily n'est utilisée que si votre application embarque la police.
• Chargement. loader est un squelette ou un indicateur de chargement. readyTimeout, 15 secondes par défaut, est le temps de chargement accordé à l'interface avant qu'elle affiche une erreur avec Réessayer.

Erreurs

Chaque échec est une WajubError.

React Native écrit ces champs en snake_case : decline_code, correlation_id, retry_after_seconds, block_reference.

Un code absent de cette liste, le code de refus propre à une banque par exemple, peut aussi vous parvenir : affichez message. Les erreurs de champ, un numéro de téléphone invalide par exemple, restent sur le formulaire et n'arrivent jamais dans onError.

Confidentialité

Les quatre SDKs, Flutter, React Native, Android et iOS, envoient les mêmes données. Quand le payeur paie, le SDK envoie à Wajub ce dont le paiement a besoin et, pour la prévention de la fraude, des informations de base sur l'appareil et un identifiant d'installation aléatoire, qui n'est pas l'identifiant publicitaire. Quand le payeur utilise le formulaire de carte de Stripe, le SDK de Stripe collecte aussi ce que Stripe documente pour ses propres contrôles antifraude.

Déclarez-le à côté de ce que votre application collecte elle-même.

Pour les étiquettes de confidentialité de l'App Store, déclarez-le lié à l'utilisateur, non utilisé pour le suivi, pour App Functionality, ce qui couvre le traitement du paiement et la prévention de la fraude.

Le SDK iOS embarque un manifeste de confidentialité, que Xcode intègre au rapport de confidentialité de votre application.

Pour la sécurité des données de Google Play, déclarez-le collecté pour App functionality et Fraud prevention, security, and compliance, partagé avec Wajub en tant que prestataire de paiement, chiffré en transit.

Tests

Un paiement que votre serveur crée avec une clé de sandbox place tout le parcours en sandbox, interface comprise, et l'interface affiche un badge « Mode test ». Rien ne change dans l'application. Les numéros et cartes de test figurent dans Scénarios de test.