Prérequis
- Cible de déploiement iOS 15.0+
- Swift 5.9+
- Un compte marchand Sezzle avec votre Clé API publique
- Un serveur backend pour capturer les paiements après le paiement
1. Installation
- Swift Package Manager
- CocoaPods
- Dans Xcode, allez à File > Add Package Dependencies
- Saisissez l’URL du dépôt :
- Sélectionnez Up to Next Major Version à partir de la dernière version
- Ajoutez
SezzleMerchantSDKà votre cible
2. Configuration
Initialisez le SDK une fois au démarrage de l’application dans votreAppDelegate :
3. Messages promotionnels
Ajoutez unSezzlePromotionalView à votre page 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 NSAttributedString 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
Gérer le résultat
Conformez-vous àSezzleCheckoutDelegate :
Après
checkoutDidComplete, envoyez result.orderUUID vers votre serveur backend. Votre serveur doit appeler POST /v2/order/{orderUUID}/capture en utilisant votre privée clé API pour capturer le paiement. Consultez l’ Orders API pour plus de détails.5. Mode WebView
Par défaut, le paiement s’ouvre dansASWebAuthenticationSession (navigateur système). Pour garder l’utilisateur dans votre application, utilisez le mode WebView :
Appareils multi-utilisateurs — effacement de la session Sezzle à la déconnexion
LeWKWebsiteDataStore.default() est un store persistant unique à l’échelle de l’application, hérité par chaque WebView avec la configuration par défaut. Les cookies définis lors du paiement .webView 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.2, appelez SezzleSDK.shared.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 :
.systemBrowser le mode partage les cookies avec Safari via ASWebAuthenticationSession et n’est pas affecté — si vos utilisateurs ont besoin de les effacer, ils doivent le faire directement dans Safari.
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 viaSezzleCheckoutDelegate.checkoutDidFail(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, 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 URLs de rappel choisies par le marchand, puis transmet order.checkout_url ainsi que ces URLs à l’application. Le SDK ouvre l’URL, intercepte la navigation vers vos URLs de rappel, et rapporte le résultat via SezzleCheckoutDelegate.checkoutDidComplete(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 complétion.
Étape 1 — Le backend crée la session
Choisissez les URLs 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.
Persister order.uuid côté serveur ; l’application n’a besoin que de order.checkout_url ainsi que des deux URLs de rappel.
Étape 2 — L’application présente le paiement
SezzleSDK.shared.configure(publicKey:) est non requis pour ce flux — il n’y a rien à authentifier pour le SDK.
Étape 3 — Lire le résultat
Notes
ASWebAuthenticationSessionnécessite un schéma d’URL personnalisé pour le rappel (paramètrecallbackURLScheme:). Les rappels HTTPS ne sont pas acceptés par l’API de session d’authentification. Pour les liens profonds basés sur HTTPS (par exemple, pris en charge par Universal Links), utilisez le mode.webView— il intercepte la navigation directement viaWKNavigationDelegateet fonctionne avec n’importe quel schéma.- Faites correspondre vos URLs. Quelles que soient les URLs que votre backend a transmises en tant que
complete_url.href/cancel_url.href, transmettez les mêmes URLs àstartCheckout. Le SDK effectue la correspondance sur le schéma + l’hôte + le chemin ; les paramètres de requête de 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 le possède déjà depuis la réponse de création de session.


