SDK Swift

Notre SDK natif vous aide à communiquer avec l'API Client. Il offre :

• Des encapsulations pratiques pour les réponses de l'API.
• La gestion de tous les détails concernant le chiffrement des informations de paiement.
• La mise en cache des logos des méthodes de paiement et des images pour offrir des informations supplémentaires sur les moyens de paiement.
• Un formatage user-friendly des données de paiement telles que les numéros de carte et les dates d'expiration.
• La validation des saisies.
• Des vérifications pour déterminer à quel émetteur un numéro de carte est associé.

Notre application de démonstration simule l'interface utilisateur pour l'ensemble du processus de paiement basé sur l'interaction entre l'application et notre plateforme. Retrouvez le code source du SDK et de l'application de démonstration sur GitHub, y compris les instructions d'installation.

Une fois que vous êtes prêt, consultez les prochains chapitres pour savoir comment préparer et utiliser le SDK.

Pour créer des paiements, vous devez d'abord intégrer le SDK à votre projet. Toutes les versions du SDK sont disponibles publiquement dans notre repository. Pour simplifier leur utilisation, nous avons préparé un package ci-dessous pour une intégration rapide.

Le SDK est disponible via les gestionnaires de packages suivants : CocoaPods, Carthage ou Swift Package Manager.

CocoaPods

Vous pouvez ajouter le SDK en tant que pod à votre projet en ajoutant le code suivant à votre Podfile :

$ pod 'OnlinePaymentsKit'

Ensuite, exécutez la commande suivante :

$ pod install

Carthage

Vous pouvez ajouter le SDK avec Carthage en ajoutant le code suivant à votre Cartfile :

$ github " wl-online-payments-direct/sdk-client-swift"

Ensuite, exécutez la commande suivante :

$ carthage update --use-xcframeworks

Naviguez vers le repository Carthage/Build qui a été créé dans le même repository que le fichier .xcodeproj ou .xcworkspace. Ce repository stocke le bundle .xcframework. Glissez le .xcframework dans la section Framework, Libraries and Embedded Content de la cible souhaitée. Assurez-vous qu'il soit configuré sur Embed & Sign.

Swift Package Manager

Vous pouvez ajouter le SDK avec Swift Package Manager en configurant votre projet comme suit :

• Allez dans les paramètres de votre projet et cliquez sur l'onglet Package Dependencies.
• Cliquez sur "+" pour ajouter une nouvelle dépendance Swift Package.
• Saisissez l'URL GitHub dans la barre de recherche : https://github.com/Online-Payments/sdk-client-swift.

De plus, vous pouvez définir une version du package que vous souhaitez inclure. L'option par défaut est de sélectionner la dernière version de la branche principale.

• Cliquez sur Add package

En conséquence, le package sera automatiquement ajouté comme dépendance à vos cibles.

Après l'intégration réussie du SDK à votre projet, vous pouvez passer au processus d'intégration avec l'ensemble du système de paiement. Le processus de paiement complet consiste en ces étapes :

1. Initialisation des objets Session et PaymentContext
2. Réception des méthodes de paiement possibles
3. Réception et affichage des détails des méthodes de paiement
4. Validation des données fournies
5. Chiffrement et transfert des données de paiement
6. Finalisation de la transaction

1. Initialiser les objets Session et PaymentContext

Tout d'abord, vous devez créer une Session permettant la communication entre l'API serveur et le client. Votre application doit avoir son propre serveur, agissant comme intermédiaire entre notre Client et l'API serveur.

Comme le client initie le paiement dans son application, l'application cliente demande à l'application serveur de créer une session. Lorsqu'une application serveur reçoit une demande, elle peut créer une session via Create Session du SDK serveur.

Après avoir configuré et connecté votre application à l'API serveur, vous recevez une réponse contenant des informations sur la session créée. Une réponse typique ressemble à ceci :

{
    "assetUrl": "https://assets.test.cdn.v-psp.com/s2s/515c2c0bd13d5dd4bd42",
    "clientApiUrl": "https://payment.preprod.ca.cawl-solutions.fr/",
    "clientSessionId": "68a4b0b183a34016b4b694b97938f75b",
    "customerId": "cf7d7aafd42e4a1cb9e4b0624a5041b1",
    "invalidTokens": []
}

Transmettez maintenant assetUrl, clientApiUrl, clientSessionId et customerId à l'application Client. Une fois que l'application reçoit une réponse de l'application Serveur avec des informations sur la Session, créez un objet local Session du côté de l'application Client.

Ensuite, créez un objet PaymentContext. Il contient des informations sur le mode de paiement, la devise, le pays, le montant, etc. Vous utiliserez les objets PaymentContext et Session tout au long du processus de paiement.

2. Recevoir les méthodes de paiement possibles

La prochaine étape consiste à obtenir et afficher les options de paiement possibles. Pour ce faire, utilisez la Session et le PaymentContext précédemment créés pour invoquer la méthode GetBasicPaymentItems, qui envoie GetPaymentProducts à notre API Serveur.

Jetez un œil à l'exemple de code montrant comment initialiser une instance de la classe PaymentContext et l'utiliser pour obtenir la liste des BasicPaymentItems avec l'objet Session.

let amountValue = 100
let countryCode = "NL"
let currencyCode = "EUR"
let isRecurring = false

let amountOfMoney = PaymentAmountOfMoney(totalAmount: amountValue, currencyCode: currencyCode)
let context = PaymentContext(amountOfMoney: amountOfMoney, isRecurring: isRecurring, 
                            countryCode: countryCode)

session.paymentItems(for: context, groupPaymentProducts: false, 
                            success: { paymentItems in
    // Permettre au client de sélectionner un élément de paiement et un compte optionnel
    // à partir de la liste des éléments de paiement
    // représentés par paymentItems.
}, failure: { error in
    // Indiquer qu'une erreur s'est produite.
})

3. Recevoir et afficher les détails de la méthode de paiement

Les éléments de paiement sont des instances de BasicPaymentProduct. Votre application peut utiliser ces éléments pour créer un écran qui les liste tous. Utilisez notre application d'exemple pratique comme base pour votre propre implémentation.

Pour certaines méthodes de paiement, les clients peuvent indiquer qu'ils souhaitent que notre plateforme stocke leurs informations d'identification pour les paiements récurrents. Nous désignons les données stockées comme un account on file (compte enregistré) ou token. Vous pouvez réutiliser ce compte enregistré / token pour des paiements ultérieurs si vos clients choisissent la même méthode de paiement.

La liste des moyens de paiement disponibles que le SDK reçoit de l'API Client contient également les accounts on file (comptes enregistrés) pour chaque moyen de paiement. Votre application peut présenter cette liste à l'utilisateur.

En fonction de la méthode choisie par le client, envisagez des cas de flux de données différents :

Si l'utilisateur a choisi une forme de paiement native, vous devez utiliser le SDK du prestataire de paiement et traiter la réponse uniquement à la dernière étape pour informer l'utilisateur de l'état du paiement. Lisez plus sur les paiements natifs dans le chapitre dédié.

Pour les paiements avec un prestataire de paiement tiers, vous recevez les données avec l'adresse de redirection dans les propriétés de paiement. Redirigez vos clients dans leur navigateur vers le portail de paiement tiers pour continuer le processus de paiement. Après le paiement réussi, votre application doit gérer la redirection vers l'application Client.

Le processus de paiement standard est un paiement par carte. Une fois que vos clients ont sélectionné un élément de paiement ou un account on file (compte enregistré), le SDK Client peut demander les informations nécessaires que vos clients doivent fournir pour le paiement.

Un objet représentant la méthode de paiement BasicPaymentItem fournit une liste des champs que votre application doit afficher, y compris les indices et règles de validation. Si vos clients sélectionnent un account on file (compte enregistré), les informations déjà disponibles peuvent être préremplies dans les champs de saisie au lieu d'être demandées à vos clients. Les données préremplies au nom du client sont conformes aux réglementations applicables. Selon le cas d'utilisation individuel, vos clients peuvent toujours avoir à fournir certaines données (par exemple, le CVC).

4. Valider les données fournies

Votre application doit maintenant valider les données saisies par vos clients dans l'interface de votre application. Pour ce faire, utilisez le composant de validation des données. L'interface de saisie des données doit être totalement transparente et compréhensible pour vos clients. Nous recommandons les ToolTips, qui comportent des champs individuels ou affichent des erreurs de validation appropriées.

5. Chiffrer et transférer les données de paiement

En fonction des données collectées, vous devez créer une instance de PaymentRequest. Cette classe possède une propriété tokenize utilisée pour indiquer si l'application doit stocker les informations d'identification du client pour des paiements récurrents.
Utilisez l'exemple de code suivant pour les demandes de paiement sans account on files (compte enregistrés) :

let paymentRequest = PaymentRequest()
paymentRequest.paymentProduct = paymentProduct
paymentRequest.tokenize = false

Alternativement, adaptez l'exemple de code en fournissant à la fois le account on file (compte enregistré) et le moyen de paiement correspondant :

paymentRequest.accountOnFile = accountOnFile

Une fois que vous avez configuré une requête de paiement, fournissez les valeurs pour les champs du moyen de paiement. Utilisez les identifiants des champs, tels que "cardNumber" et "cvv" pour définir les valeurs des champs pour la requête de paiement :

paymentRequest.setValue("1234567890", forField: "cardNumber")
paymentRequest.setValue("123", forField: "cvv")

Vous pouvez maintenant valider la requête de paiement. En conséquence, une liste d'erreurs est disponible. Pour toute erreur de validation, vous devez fournir un retour d'information au client. Pour plus d'informations, lisez le chapitre dédié.

paymentRequest.validate()
if paymentRequest.errors.count == 0 {
    // La requête de paiement est valide et peut être chiffrée et envoyée à
    // notre plateforme via le serveur du marchand.
}
else {
    // Informez l'utilisateur que certains champs contiennent des données invalides.
}

Après la validation de PaymentRequest, chiffrez la requête et envoyez-la à votre application serveur. Jetez un œil à l'exemple de code montrant comment utiliser une instance de Session pour chiffrer une requête :

session.prepare(paymentRequest, success: { preparedPaymentRequest in
    // Soumettez les informations contenues dans la requête de paiement
    // chiffrée représentée par preparedPaymentRequest
    // à notre plateforme via votre serveur.
}, failure: { error in
    // Indiquez qu'une erreur s'est produite.
})

6. Finaliser la transaction

Après avoir reçu les données chiffrées, transmettez-les à votre serveur d'application pour finaliser le paiement en envoyant une demande CreatePayment.

Pour terminer, vous devez transmettre l'information à l'application Client pour afficher le résultat de la transaction à vos clients.

Objets SDK

Le SDK inclut plusieurs objets. Choisissez l'objet qui vous intéresse dans la liste ci-dessous pour en savoir plus à son sujet :

• C2sCommunicator
• Session
  • Device Metadata
• PaymentContext
  • AmountOfMoney
  • PaymentItemCacheKey
• BasicPaymentItem interface
  • BasicPaymentProduct
  • PaymentProduct
    • PaymentProductField
• AccountOnFile
• DisplayHints
  • ToolTips
  • FormElement
• PaymentRequest
• PreparedPaymentRequest
• Responses

C2sCommunicator

C'est le principal service de communication. Vous ne l'utilisez pas directement, mais uniquement via l'objet Session. Il crée une connexion sécurisée avec notre API Client.

Session

Session est le composant principal du SDK. L'objet :

• Enveloppe C2sCommunicator en implémentant toute la logique de communication avec notre API Client.
• Crée des requêtes API appropriées.
• Est responsable de la conversion des réponses de l'API en objets natifs simples.
• Dispose d'un chiffrement intégré des objets natifs décrivant la requête de paiement de manière à ce que notre API Serveur puisse la traiter.

Assurez-vous d'initialiser correctement Session pour commencer la communication avec notre API Client. Les propriétés obligatoires sont :

• client session identifier
• customer identifier
• url-api-client
• url-base-ressource

Vous obtiendrez ces paramètres en utilisant le CreateSession de l'endpoint de l'API Serveur. Reportez-vous aux SDKs Serveur et à l'API Serveur pour en savoir plus.

La classe C2sCommunicatorConfiguration possède des méthodes statiques pour initialiser Session :

let clientSessionId = "1234"
let customerId = "5678"
let clientApiUrl = "https://clientapi.com"
let assetBaseURL = "https://asset.com"
let applicationIdentifier = "Exemple Application/v1"

var session = Session(clientSessionId: clientSessionId, customerId: customerId,
                            clientApiUrl: clientApiUrl, assetBaseURL: assetBaseURL, applicationIdentifier: applicationIdentifier)

Assurez-vous de savoir si l'application fonctionne en production et de spécifier l'identifiant de l'application lors de l'initialisation. Un paramètre supplémentaire spécifie l'adresse IP. L'adresse IP et l'identifiant de l'application sont utilisés dans les Device Metadata lors de la communication avec l'API Client.

Propriétés

string clientSessionId : L'identifiant de la session créée. string customerId : La session est basée sur le client sous la forme de customerId. Toutes les API Client utilisent cet customerId dans l'URI pour identifier le client. string clientApiUrl : L'URL de base spécifique au centre de données pour les requêtes Client. Transmettez cette valeur au SDK Client pour vous assurer que le logiciel Client se connecte au bon centre de données. string assetBaseUrl : L'URL de base spécifique au centre de données pour les ressources. string applicationIdentifier : L'identifiant de l'application.

Device Metadata

Les Device Metadata incluent les données suivantes :

Propriétés

platformIdentifier : Contient la version et le type du système appIdentifier : L'identifiant de l'application fourni par l'utilisateur, sinon défini par "inconnu" sdkIdentifier : La version du Client SDK sdkCreator : Le nom de l'éditeur du Client SDK screensize : La taille de l'écran de l'appareil deviceBrand : Le fabricant de l'appareil deviceType : Le modèle de l'appareil ipAddress : Le paramètre optionnel avec l'adresse IP publique de l'appareil

PaymentContext

Les instances de la classe PaymentContext contiennent les informations de paiement les plus pertinentes, telles que :

• amountOfMoney
• currency
• countryCode
• isRecurring – une indication de si le paiement est un paiement unique ou Card On File.

Cet objet :

• Participe aux prochaines étapes de la transaction.
• Doit rester sous la même forme après l'initialisation – vous devez utiliser le même objet durant tout le processus de transaction.

AmountOfMoney

Ce modèle contient des informations sur le montant du paiement. Il se compose de amount exprimé dans le type long et de la devise donnée sous la forme currencyCode.

Notez que le montant inclut des fractions de monnaie. L'objet ci-dessous est équivalent à 1 EUR.

"amountOfMoney": {
            "amount": 100,
    "currencyCode": "EUR"
        },

PaymentItemCacheKey

Un modèle supplémentaire utilisé dans le mécanisme de cache. Au cours d'une même session, sont stockées les relatives à une tentative de paiement. En cas de tentative répétée, le mécanisme n'effectue pas une autre requête mais utilise le cache.

Interface BasicPaymentItem

L'interface principale de BasicPaymentItem est principalement responsable de l'identification et d'une présentation visuelle simple de l'item de paiement. Elle a :

• Un identifiant ID.
• Une liste de DisplayHints qui contient le texte visuel publicitaire (par exemple, un logo ou l'image de la carte avec le CVC marqué).
• Une caractéristique distinctive de la méthode de paiement (par exemple, un logo).
• Des informations sur les instances AccountOnFile associées.

BasicPaymentProduct

Contient une liste de méthodes de paiement disponibles. Le client peut sélectionner une méthode parmi cette liste. Chaque instance contient :

• Un identifiant.
• Un champ indiquant le moyen de paiement.
• Deux champs qui indiquent le montant minimal et maximal requis pour payer avec ce moyen de paiement.
• Un champ indiquant si notre plateforme peut enregistrer les données de paiement en tant que compte à enregistrer pour des paiements ultérieurs.
• Un champ indiquant si la méthode permet Card On File.
• Un champ indiquant si la méthode de paiement utilise une redirection vers un tiers.
• Une liste de comptes précédemment enregistrés pour ce moyen de paiement.
• Affiche des indices pour rendre BasicPaymentProduct correctement, contenant :
  • Un index indiquant à quelle position le moyen de paiement appartient dans une liste de moyens de paiement
  • Un libellé
  • Un logo

PaymentProduct

Il étend la classe BasicPaymentProduct et implémente l'interface PaymentItem qui complète le modèle avec la liste PaymentProductField. Cependant, une fois que le client sélectionne un élément de paiement ou un compte enregistré, il doit fournir des informations supplémentaires (par exemple, une adresse, un numéro de compte bancaire, un numéro de carte de crédit ou une date d'expiration) pour traiter le paiement réel.

Chaque élément de paiement peut avoir plusieurs champs que le client doit remplir pour traiter les paiements. Les instances de PaymentProductField représentent des informations sur les champs des éléments de paiement. Utilisez-le pour récupérer les instances de PaymentProduct :

// Obtenez tous les BasicPaymentItems disponibles pour paymentContext 

session.paymentItems(for: context, groupPaymentProducts: false, 
                            success: { paymentItems in
    // Permettre au client de sélectionner un élément de paiement et un 
    // compte enregistré facultatif dans la liste des éléments de paiement
    // représentée par paymentItems.
}, failure: { error in
    // Indiquer qu'une erreur s'est produite.
})

PaymentProductField

Il représente les champs des éléments de paiement. Chaque champ a :

• Un identifiant
• Type
• Une définition des restrictions qui s'appliquent à la valeur du champ
• Des informations sur la façon de présenter le champ au client dans l'interface utilisateur

Le modèle dispose d'une méthode de validation des données intégrée pour déterminer si une valeur donnée est valide pour le champ. La méthode est basée sur DataRestrictions. Elle renvoie ValidationErrorMessages et des méthodes pour masquer et décaster la valeur à l'aide du StringFormatter intégré.

L'extrait de code ci-dessous montre comment récupérer le champ avec l'identifiant "cvv" d'un moyen de paiement. Dans ce processus, nous :

• Examinons les restrictions de données du champ pour voir si ce champ est requis ou facultatif.
• Examinons les indices d'affichage du champ pour voir si les valeurs fournies par un client doivent être masquées dans une interface utilisateur.
• Validons la valeur "123".
• Examinons le nombre d'erreurs de validation pour voir si la valeur fournie est valide.

if let field = paymentProduct.paymentProductField(withId: "cvv") {
    let isRequired = field.dataRestrictions.isRequired
    let obfuscate = field.displayHints.obfuscate
    field.validateValue("123")
    let validValue = field.errors.count == 0
}

AccountOnFile

AccountOnFile représente les informations sur un compte enregistré pour un certain moyen de paiement. Il contient :

• Un identifiant pour le compte enregistré.
• Un identifiant pour le moyen de paiement correspondant.
• Une collection de paires clé-valeur enregistrées dans le cadre du compte enregistré.
• Des indices d'affichage qui contiennent des informations sur la façon de rendre le compte enregistré.
• Une méthode qui produit un libellé décrivant le compte enregistré

Récupérez des instances de AccountOnFile en tant qu'instances de BasicPaymentProduct comme suit :

@objc public func getSelectedAccountOnFile(withPaymentItem paymentItem: BasicPaymentProduct, withIdentifier selectedAccountOnFileId: String) {
		let accountOnFile = product.accountOnFile(withIdentifier: selectedAccountOnFileId)
        return accountsOnFile
}

DisplayHints

DisplayHints sont des objets contenant des indications. Il existe trois types de DisplayHints :

• DisplayHintsPaymentItem : Les informations les plus importantes sur PaymentItem, c'est-à-dire un nom et un logo. Une propriété supplémentaire est displayOrder qui indique l'ordre d'affichage approprié selon l'index d'ordre par rapport aux autres PaymentItems utilisés par BasicPaymentItems et BasicPaymentProducts. Utilisez-les pour afficher la liste de sélection PaymentItem.
• DisplayHintsAccountOnFile : La liste contenant les paires clé-valeur ProductFields et le masque correspondant pour appliquer le masque (par exemple, des astérisques) à la valeur correspondante de AccountOnFile.
• DisplayHintsProductFields : Définit le mode d'affichage des ProductFields. En plus du nom et du texte de substitution, il contient PreferredInputType, sur la base duquel vous pouvez choisir :
  • Le type de clavier approprié à utiliser
  • Si l'élément doit toujours être affiché comme AlwaysShow
  • Si la valeur Obfuscate doit être masquée, ainsi que la valeur de Mask - une référence à ToolTip et FormElement assignés

ToolTips

ToolTips facilitent la saisie des données. Vous pouvez ajouter un objet ToolTip dans les indications d'affichage pour ProductFields. Il peut contenir un texte explicatif ou un graphique, c'est-à-dire une photo d'une carte avec un CVV masqué.

FormElement

Une description simplifiée de l'élément visuel vous indiquant comment l'utiliser correctement en tant que texte, liste, devise, date ou booléen.

PaymentRequest

Cette classe encadre la relation entre le PaymentProduct sélectionné, AccountOnFile et les valeurs saisies. Elle vous permet d'extraire facilement les valeurs masquées ou non masquées. Elle contient une méthode de validation des données saisies. Consultez le chapitre dédié au chiffrement pour plus d'informations.

PreparedPaymentRequest

L'instance de la classe PreparePaymentRequest est le résultat du chiffrement d'une requête à l'aide d'une instance de Session. Elle possède deux propriétés, encryptedFields et encodedClientMetaInfo – les chaînes de caractères qui doivent être envoyées à notre plateforme. Consultez le chapitre dédié au chiffrement pour plus d'informations.

Responses

• ApiResponse : Chaque requête est encadrée dans une réponse API contenant des données génériques. En cas d'erreur, dans le champ additionnel. ErrorResponse, vous pouvez trouver ApiErrorCode et Message décrivant l'erreur.
• PublicKeyResponse : API client que vous utilisez pour récupérer une clé publique spécifique à la transaction depuis notre serveur. Utilisez-la pour chiffrer les données sensibles, c'est-à-dire les détails de la carte. Cet objet renvoie automatiquement une clé publique déjà déchiffrée depuis notre API.

Fonctionnalités supplémentaires

Le SDK a beaucoup plus à offrir. Jetez un œil aux fonctionnalités suivantes, car elles vous aideront à construire la solution parfaite.

• Chiffrer les données sensibles
• Valider les données
• Appliquer la vérification IIN
• Implémenter des paiements natifs
• Utilisation de Logs
• Utiliser l'application de démonstration

Chiffrer les données sensibles

L'un des plus grands atouts du SDK est son outil de chiffrement. Il offre une grande sécurité lors du transfert de données sensibles (c'est-à-dire les numéros de carte, la date d'expiration, le code CVC). Un flux complet de chiffrement/transfert ressemble à ceci :

Vous n'avez pas besoin de réaliser toutes ces étapes par vous-même. Grâce au SDK, vos tâches sont les suivantes :

1. Lorsque vos clients ont rempli tous les champs de paiement requis et ont confirmé le paiement, créez l'objet PaymentRequest, assignez-lui le PaymentProduct sélectionné et remplissez-le avec les valeurs saisies.
2. Validez la PaymentRequest créé en utilisant la méthode Validate.
3. S'il n'y a pas d'erreurs de validation, utilisez un objet Session et appelez la méthode PreparePaymentRequest. Celle-ci effectuera l'intégralité du processus de chiffrement pour vous et renverra les données chiffrées.
4. Envoyez les données chiffrées à votre serveur.
5. Votre serveur envoie les données chiffrées en utilisant la méthode CreatePayment dans le champ du corps de la requête – encryptedCustomerInput.
6. Vous envoyez le résultat de la transaction à l'application cliente.

L'algorithme utilisé est RSA-OAEP avec un encodage A256CBC-HS512. Il est possible de mettre en œuvre votre propre chiffrement, mais vous manquerez les fonctionnalités d'aide que l'encrypteur offre. Nous ne garantissons pas le bon fonctionnement en cas de données mal chiffrées. Notez que nous ne sommes pas en mesure de vérifier les données chiffrées pour détecter des erreurs. Par conséquent, vous devez vous assurer que toutes les opérations précédentes ont été effectuées correctement.

Valider les données

Chaque PaymentProductField possède des DataRestrictions appropriées. L'objet DataRestrictions contient des informations sur tous les champs obligatoires et vérifie si les valeurs saisies répondent aux conditions de validité. En plus d'une liste de validateurs abstraits, il possède aussi une propriété isRequired indiquant si les restrictions données sont requises ou non.

Vous pouvez valider une saisie particulière aussi facilement qu'en passant par la validation de PaymentRequest. En cas d'erreurs, le champ Errors affichera une liste d'erreurs.

Il contient les validateurs suivants :

• Date d'expiration : Vérifie si la date d'expiration de la carte saisie n'est pas antérieure à la date actuelle et si elle ne dépasse pas une période de vingt-cinq ans à venir.
• Adresse e-mail : Vérifie le format de l'adresse e-mail fournie par le client.
• Liste fixe : Vérifie si la valeur saisie figure sur la liste des possibilités.
• IBAN : Valide l'IBAN fourni par le client.
• Longueur : Vérifie si la valeur saisie est plus longue que la valeur minimale et si elle ne dépasse pas la longueur maximale.
• Luhn : La formule de somme de contrôle utilisée pour valider divers numéros d'identification, tels que les numéros de carte de crédit.
• Plage : Vérifie si la valeur est supérieure à la valeur minimale et si elle ne dépasse pas la valeur maximale.
• Regex : Valide si la valeur saisie correspond à l'expression régulière.
• Conditions générales : Le validateur booléen pour le champ d'acceptation des conditions générales.

Chaque validateur retourne une erreur appropriée, indiquant un champ qui ne répond pas aux conditions, et un message que vous pouvez facilement traduire.

Appliquer la vérification IIN

Les huit premiers chiffres d'un numéro de carte de paiement sont connus sous le nom de Issuer Identification Number (IIN).

Vous pouvez utiliser une instance de Session pour vérifier quels moyens de paiement sont associés à un IIN. La vérification est effectuée de manière asynchrone, donc le résultat de la vérification n'est pas disponible immédiatement. Le résultat est une instance de IinDetailsResponse. Cette classe possède les propriétés suivantes :

• paymentProductId : La méthode de paiement principale associée à cet IIN.
• countryCode : Le code pays de la méthode de paiement principale associée à cet IIN.
• status : Type de IinStatus qui indique le résultat de la vérification de l'IIN. Les statuts possibles sont :
  • SUPPORTED: L'IIN est associé à un moyen de paiement
  • NOT_ENOUGH_DIGITS: Moins de six chiffres ont été fournis
  • EXISTING_BUT_NOT_ALLOWED: L'IIN est reconnu, mais il ne peut pas être utilisé pour le paiement actuel
• isAllowedInContext : Indique s'il est permis de réaliser un paiement avec le moyen de paiement principal basé sur le PaymentContext
• coBrands : Une liste d'instances de IinDetail, qui décrivent les co-marques pour l'IIN actuel.

Il est possible qu'une seule carte de crédit ait plusieurs marques associées et soit ainsi 'co-badgée'. Les détails du premier moyen de paiement que vos clients peuvent utiliser pour effectuer le paiement dans ce contexte sont toujours stockés dans les champs principaux du IinDetailsResponse. Si le co-badgeage s'applique, la liste des instances de IinDetail contient toutes les marques associées à la carte, y compris le moyen de paiement qui est stocké dans les champs principaux. Utilisez cette liste pour permettre aux clients de choisir leur marque préférée. S'il n'y a qu'un seul moyen de paiement associé à la carte de crédit, la liste des détails IIN est vide.

func doIINLookup() {
    guard let unmasked = paymentRequest.unmaskedValue(forField: "cardNumber") else {
        fatalError("La requête de paiement ne contient pas le champ cardNumber")
    }

    session.iinDetails(forPartialCreditCardNumber: unmasked, context: context, success: { response in
        if response.status == .supported {
            if !response.coBrands.isEmpty {
                if !self.isSelectedPaymentProduct(inCoBrands: response.coBrands) {
                    self.switchToPaymentProduct(response)
                }

                // La législation de l'UE exige que, en cas de
                // carte avec plusieurs marques, un client puisse
                // choisir la marque avec laquelle il veut faire le paiement.

                self.showCoBrandNotification()
            } else if response.paymentProductId != self.paymentItemIdentifier {
                self.switchToPaymentProduct(response)
            }
        }
        else {
            // Gérer d'autres codes de statut.
        }
    }, failure: { error in
        // Indiquer qu'une erreur s'est produite.
    })
}

func isSelectedPaymentProduct(inCoBrands cobrands: [IINDetail]) -> Bool {
    return cobrands.contains { $0.paymentProductId == paymentItemIdentifier }
}

func switchToPaymentProduct(_ response: IINDetailsResponse) {
    if response.allowedInContext, let itemId = response.paymentProductId {
        // Passer au moyen de paiement qui est effectivement dans le niveau supérieur
        // de la réponse des détails IIN.
        paymentItemIdentifier = itemId
    }
    else {
        // Fournir au client un message d'erreur montrant que le
        // numéro de carte de crédit qu'il est en train de saisir ne peut actuellement pas être utilisé pour payer.
        // Montrez au client qu'il peut choisir une autre marque pour payer.
    }
}

func showCoBrandNotification() {
    // Montrez au client qu'il peut choisir une autre marque pour payer.
}

Mettre en œuvre des paiements natifs

Par paiements natifs pour les appareils mobiles, nous entendons Google Pay pour Android et Apple Pay pour les appareils iOS. Notre système prend en charge les paiements natifs, mais cela ne signifie pas qu'ils seront disponibles sur chaque appareil.

Si l'utilisateur reçoit un moyen de paiement responsable du paiement natif, le SDK vérifie automatiquement si l'appareil est capable de gérer le paiement. Si l'appareil ne répond pas aux conditions requises, ce paiement est masqué. Grâce à cette procédure, vous, en tant qu'utilisateur de notre produit, n'avez pas à vous soucier de vérifier la validité de l'opération.

Pour les appareils avec iOS, vous vérifiez si le système respecte le critère de version minimale (8.0) et utilisez le PKPaymentAuthorizationViewController pour vérifier s'il est possible d'effectuer la transaction.

Écran de saisie de la méthode de paiement

Cet écran est un autre exemple d'écran qui apparaîtra dans la plupart des applications utilisant le SDK. L'application l'affiche après avoir sélectionné un élément de paiement ou un compte en mémoire. Si le client a sélectionné un compte en mémoire, certaines des valeurs requises seront préremplies et ne pourront pas être modifiées. Le formulaire de saisie est généré à partir d'une instance de PaymentProduct.

Validation du formulaire

L'application de démonstration utilise le SDK pour valider les saisies des clients lorsqu'ils appuient sur le bouton Payer. Si les données fournies sont invalides, des messages d'erreur sont affichés sous les valeurs invalides.

Informations complémentaires

Certains champs du paiement peuvent nécessiter des explications supplémentaires. Le bouton d'information à côté du champ de texte pour le code CVV, montré ci-dessous, indique que des informations supplémentaires sont disponibles. L'image affichée lorsque le client appuie sur le bouton fait partie des indices d'affichage du champ de moyen de paiement. L'explication textuelle est une chaîne localisée qui fait partie du SDK.

Vérification de l'IIN

L'application de démonstration démontre également l'utilisation de la vérification de l'IIN décrite ci-dessus. Pour chacun des moyens de paiement basés sur les cartes, une vérification de l'IIN est effectuée dès que le client a entré six chiffres ou plus dans le champ de texte pour le numéro de carte. Si l'IIN est associé au moyen de paiement sélectionné, le logo de ce moyen de paiement apparaît sur le côté droit du champ de texte. Si l'IIN est associé à une autre méthode de paiement, les champs de saisie sont automatiquement remplacés par les champs de saisie pour le nouveau moyen de paiement.

La capture d'écran montre également comment les co-badgeages qui peuvent être associés à une certaine carte peuvent être rendus. Le logo du moyen de paiement et le nom des co-badgeages sont récupérés en effectuant des appels spécifiques pour eux.