Prérequis
- Android 6.0+ (API 23), compileSdk 35+
- Kotlin ou Java
- Un compte marchand Sezzle avec votre Clé API publique
- Un serveur backend pour capturer les paiements après le paiement
1. Installation
- Gradle (Kotlin DSL)
- Gradle (Groovy)
Ajoutez à votre module d’application
build.gradle.kts :2. Configuration
Initialisez le SDK une fois au démarrage de l’application dans votreApplication class:
3. Messages promotionnels
Ajoutez unSezzlePromotionalView à votre écran produit pour afficher la tarification en versements :

Widgets promotionnels à différents niveaux de prix
Tous les paramètres
Configuration du widget
Tous les paramètres de configuration sont optionnels — le widget fonctionne immédiatement avec des valeurs par défaut sensées :
Pour personnaliser, ne passez que les valeurs que vous souhaitez remplacer :
Texte promotionnel personnalisé
Si vous avez besoin d’un contrôle total sur l’interface utilisateur, utilisezSezzlePromoDataHandler pour obtenir un SpannableString stylisé avec le logo Sezzle intégré :
4. Paiement
Construire l’objet de paiement
Champs client
Champs de commande
Champs d’adresse (SezzleAddress)
Démarrer le paiement
Le
activity paramètre doit être un ComponentActivity (ex. : AppCompatActivity). Le SDK utilise l’API Activity Result en interne.Gérer le résultat
ImplémentezSezzleCheckoutListener :
Après
onCheckoutComplete, envoyez result.orderUUID à votre serveur backend. Votre serveur doit appeler POST /v2/order/{orderUUID}/capture en utilisant votre privée Clé API pour capturer le paiement. Voir le Orders API pour plus de détails.5. Mode WebView
Par défaut, le paiement s’ouvre dans Chrome Custom Tabs — un onglet de navigateur sécurisé qui s’exécute dans son propre processus et partage les cookies avec Chrome (connexion plus rapide pour les utilisateurs Sezzle récurrents). Pour garder l’utilisateur dans votre application, utilisez le mode WebView :Variante sécurisée pour le cycle de vie (recommandée pour WebView)
Si votre activité hôte peut être détruite et recréée pendant que le paiement est à l’écran — par exemple sous l’option développeur Android « Ne pas conserver les activités », sous des limites agressives de processus en arrière-plan, ou sous une pression mémoire réelle sur les appareils à faible RAM — préférez lastartCheckoutForResult surcharge introduite dans 1.2.4. Elle transmet le résultat via l’Activity Result API d’Android, qui se rattache lors de la recréation de l’activité, de sorte que le rappel atteint de manière fiable l’instance active lorsque le paiement se termine. Le chemin basé sur les listeners ci-dessus stocke votre rappel dans un champ statique ; si votre activité est recréée en cours de paiement, ce rappel peut cibler une instance détruite et le résultat peut être perdu.
Enregistrez le launcher en tant que champ sur votre activité (Android exige que registerForActivityResult soit appelé avant que l’activité n’atteigne STARTED) :
WEB_VIEW. Pour le paiement SYSTEM_BROWSER (Chrome Custom Tabs), continuez à utiliser le startCheckout basé sur les listeners — le flux Custom Tabs a un profil de recréation différent et ne présente pas le même risque de cycle de vie.
Appareils multi-utilisateurs — effacement de la session Sezzle lors de la déconnexion
L’CookieManager d’Android est un singleton persistant à l’échelle de l’application. Les cookies définis lors du paiement WEB_VIEW d’un utilisateur (jetons d’authentification, identifiants de session) persistent entre les utilisateurs sur le même appareil — ainsi, si votre application prend en charge plusieurs utilisateurs (par exemple, un flux de déconnexion/connexion sur un appareil partagé), la première tentative BNPL de l’utilisateur suivant peut reprendre la session Sezzle de l’utilisateur précédent et exposer son état (refus de limite de crédit, etc.) au mauvais client.
À partir de 1.2.5, appelez SezzleSDK.clearWebViewData() depuis votre flux de déconnexion pour effacer les cookies et le stockage Web de Sezzle avant que l’utilisateur suivant ne se connecte :
CookieManager.acceptCookie() à l’échelle de l’application (les modes confidentialité/RGPD/DNT ne sont pas modifiés silencieusement).
SYSTEM_BROWSER Le mode partage les cookies avec Chrome et n’est pas affecté — si vos utilisateurs ont besoin de les effacer, ils doivent le faire dans Chrome lui-même.
6. Mode sombre
Le SDK s’adapte automatiquement au paramètre d’apparence de l’appareil. Le widget promotionnel, la modale d’acomptes et la modale de paiement prennent tous en charge le mode sombre.- Clair
- Sombre

7. Gestion des erreurs
Toutes les erreurs sont transmises viaSezzleCheckoutListener.onCheckoutError(error) :
8. Intégration pilotée par le serveur
Pour les marchands plus importants qui préfèrent une intégration entièrement pilotée par le serveur — sans clé publique sur l’appareil, avec le backend gérant la création de session, la capture et les remboursements — utilisez la surcharge alternativestartCheckout introduite dans 1.2.0.
Fonctionnement
Votre backend crée la session de paiement viaPOST /v2/session avec des URL de rappel choisies par le marchand, puis transmet order.checkout_url ainsi que ces URL à l’application. Le SDK ouvre l’URL, intercepte la navigation vers vos URL de rappel, et rapporte via SezzleCheckoutListener.onCheckoutComplete(result) avec l’URL de rappel complète — vous pouvez ainsi encoder votre propre état dans la chaîne de requête et le récupérer à la fin.
Étape 1 — Le backend crée la session
Choisissez les URL de rappel que vous souhaitez — un schéma personnalisé commeyourapp-sezzle://... ou des liens profonds HTTPS. Vous pouvez encoder l’état dans la chaîne de requête (par exemple yourapp-sezzle://done?orderRef=12345) et le récupérer depuis le rappel du SDK.
Persistez order.uuid côté serveur ; l’application n’a besoin que de order.checkout_url ainsi que des deux URL de rappel.
Étape 2 — L’application présente le paiement
SezzleSDK.configure(...) est non requis pour ce flux — il n’y a rien à authentifier pour le SDK.
Étape 3 — Lire le résultat
Note sur le manifeste pour le mode SYSTEM_BROWSER
SYSTEM_BROWSER Le mode ouvre le paiement dans Chrome Custom Tabs et achemine la redirection via le système d’intent du système d’exploitation. Le SDK inclut un intent-filter pour sezzle-sdk://checkout uniquement — si vous utilisez un schéma de rappel personnalisé, enregistrez un intent-filter pour votre schéma dans votre propre AndroidManifest.xml, pointant vers SezzleRedirectActivity :
WEB_VIEW Le mode n’a pas besoin de modification du manifeste — tout schéma est intercepté directement par le client WebView.
Notes
- Faites correspondre vos URL. Quelles que soient les valeurs que votre backend a transmises en tant que
complete_url.href/cancel_url.href, transmettez les mêmesUriàstartCheckout. Le SDK effectue la correspondance sur le schéma + l’hôte + le chemin ; les paramètres de requête sur l’URL entrante sont lus par vous. order.uuidréside sur votre serveur. Il n’est pas dans lecheckout_urlet n’est pas renvoyé — votre backend l’a déjà depuis la réponse de création de session.


