SDK Flutter

Ciblez l'URL de base de l'API la plus à jour

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 moyens de paiement et la mise en cache des images pour offrir des informations supplémentaires sur les moyens de paiement.
• Un formatage convivial des données de paiement telles que les numéros de carte et les dates d'expiration.
• La validation des entrées.
• Des vérifications pour déterminer avec quel émetteur un numéro de carte est associé.

Trouvez le code source du SDK sur GitHub, y compris les instructions d'installation.

Une fois que vous êtes prêt, lisez les chapitres suivants sur la manière de préparer et d'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 l'intégration, nous avons préparé un package ci-dessous pour un accès rapide.

Le SDK est disponible via pub.dev.

Pubspec

Vous pouvez ajouter le SDK en tant que dépendance à votre projet en ajoutant le code suivant à votre pubspec.yaml où ‘x.y.z’ est le numéro de version :

$ dependencies:

// autres dépendances

online_payments_sdk: ^x.y.z

Ensuite, exécutez la commande suivante :

$ flutter pub get

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 se compose des étapes suivantes :

1. Initialisation des objets Session et PaymentContext
2. Réception des méthodes de paiement possibles
3. Réception et affichage des détails de la méthode 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 un intermédiaire entre notre API Client et Serveur.

Étant donné que le client initie le paiement dans son application, l'application client demande à l'application serveur de créer une Session. L'application serveur peut y parvenir en utilisant la fonctionnalité Créer une Session depuis le 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.direct.worldline-solutions.com/",
         "clientSessionId": "68a4b0b183a34016b4b694b97938f75b",
         "customerId": "cf7d7aafd42e4a1cb9e4b0624a5041b1",
         "invalidTokens": []
    }

Transmettez ensuite 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 PaymentContext objet. Il contient des informations sur la forme 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

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

Jetez un coup d'œil à l'exemple de code ci-dessous montrant comment initialiser une instance de la classe PaymentContext, comment initialiser une instance de BasicPaymentProductsResponseListener, et les utiliser pour obtenir la liste BasicPaymentProducts avec l'objet Session :

int amountValue = 100;
String countryCode = "NL";
String currencyCode = "EUR";
bool isRecurring = false;

AmountOfMoney amountOfMoney = AmountOfMoney(amountValue, currencyCode);
PaymentContext context = PaymentContext(amountOfMoney, countryCode, isRecurring);


BasicPaymentProductsResponseListener listener = BasicPaymentProductsResponseListener(
onSuccess: (paymentProducts) {
  	// Permettre au client de sélectionner un élément de paiement et un
  	// compte facultatif sur fichier à partir de la liste des produits
  	// de paiement représentés par paymentProducts.
},
onError: (apiError) {
  	// Indiquer qu'une erreur s'est produite.
},
onException: (throwable) {
  	// Indiquer qu'une erreur s'est produite.
}
);

await session.getBasicPaymentProducts(
request: BasicPaymentProductsRequest(paymentContext: context),
listener: listener
);

3. Recevoir et afficher les détails des méthodes 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.

Pour certaines méthodes de paiement, les utilisateurs peuvent indiquer s'ils souhaitent que notre plateforme stocke leurs informations d'identification dans Card On File. Nous faisons référence aux données stockées en tant que compte enregistré ou token. Vous pouvez réutiliser ces comptes enregistrés / tokens pour des paiements ultérieurs si vos utilisateurs choisissent la même méthode de paiement.

La liste des méthodes de paiement disponibles envoyée par le SDK vers votre application Cliente contient également les comptes enregistrés pour chaque méthode de paiement. Votre application Cliente peut alors présenter cette liste à l'utilisateur.

En fonction de la méthode choisie par l'utilisateur, vous pouvez envisager les cas suivants :

Si l'utilisateur a choisi une méthode de paiement native, vous devez utiliser le SDK du fournisseur de paiement et gérer 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 fournisseur de paiement tiers, vous recevez des 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 compte enregistré, le Client SDK 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 rendre, y compris les indices d'affichage et les règles de validation. Si vos clients sélectionnent un 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 pourraient encore avoir à fournir certaines données (c'est-à-dire 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 entièrement transparente et compréhensible pour vos clients. Nous recommandons les ToolTips, qui possèdent des champs individuels ou affichent les erreurs de validation appropriées.

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

Sur la base des données collectées, vous devez créer une instance de PaymentRequest. Cette classe a une propriété tokenize utilisée pour indiquer si l'application doit stocker les informations d'identification du client pour les paiements Card On File. Utilisez l'exemple de code suivant pour les demandes de paiement sans tokenisation et sans comptes enregistrés :

PaymentRequest paymentRequest = PaymentRequest(paymentProduct: paymentProduct);

Si vous souhaitez tokeniser la requête de paiement, vous pouvez soit la fournir dans le constructeur, soit définir la propriété ultérieurement :

PaymentRequest paymentRequestTokenized = 
PaymentRequest(paymentProduct: paymentProduct, tokenize: true);

// Ou définir la propriété sur une requête de paiement existante
paymentRequest.tokenize = true;

Un compte enregistré peut être fourni de manière similaire :

PaymentRequest paymentRequestTokenized = 
PaymentRequest(paymentProduct: paymentProduct, accountOnFile: accountOnFile);

// Ou définir la propriété sur une requête de paiement existante
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 de la requête de paiement :

paymentRequest.setValue("cardNumber", "1234567890");
paymentRequest.setValue("cvv", "123");

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é.

List errors = await paymentRequest.validate();

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

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

PaymentRequestPreparedListener listener = PaymentRequestPreparedListener (
onSuccess: (preparedPaymentRequest) {
  	// Soumettez les informations contenues dans la
    	// requête de paiement chiffrée représentée par preparedPaymentRequest
    	// à notre plateforme via votre serveur.
},
onError: (apiError) {
  	// Indiquer qu'une erreur s'est produite.
},
onException: (throwable) {
  	// Indiquer qu'une erreur s'est produite.
}
);

await session.preparePaymentRequest(
request: SdkPreparePaymentRequest(paymentRequest),
listener: listener
);

6. Finaliser la transaction

Après avoir reçu les données chiffrées, transmettez-les à l'API Server pour finaliser le paiement en envoyant une requête CreatePayment.

Enfin, vous devez afficher le résultat de la transaction à vos utilisateurs.

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 :

• Session
  • Device Metadata
• PaymentContext
  • AmountOfMoney
• BasicPaymentProduct
• PaymentProduct
  • PaymentProductField
• AccountOnFile
• DisplayHints
  • Tooltip
  • FormElement
• PaymentRequest
• PreparedPaymentRequest
• ErrorResponse
  • ApiError

Session

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

• Est le point d'entrée pour interagir avec nos SDKs natifs
• Contient toutes les fonctions pouvant être appelées sur l'API Client
• Est responsable de la conversion des réponses de l'API en objets Dart simples à l'aide de listeners

Pour établir une communication avec l'API Client, il est crucial d'initialiser correctement la Session. Les propriétés obligatoires pour l'initialisation incluent :

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

Vous obtiendrez ces paramètres en utilisant CreateSession depuis l'API endpoint de l'API Serveur. Consultez les SDKs Serveur et l'API Serveur pour en savoir plus.

Lors de l'initialisation, déterminez si l'application est en production et spécifiez l'identifiant de l'application. Un paramètre supplémentaire vous permet de contrôler si les requêtes et réponses réseau sont enregistrées dans la console.

L'identifiant de l'application est utilisé dans les Métadonnées de l'appareil du SDK natif 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 ce 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. Passez 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 actifs. bool isEnvironmentProduction : Si le SDK est utilisé ou non dans un environnement de production. string applicationIdentifier : L'identifiant de l'application. bool loggingEnabled : Si les requêtes et réponses réseau doivent être enregistrées dans la console. Par défaut, désactivé. Doit être désactivé en production.

Métadonnées de l'appareil

Les Métadonnées de l'appareil 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 réglé sur "unknown". sdkIdentifier : La version du SDK Client. sdkCreator : Le nom de l'éditeur du SDK Client. 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.

Contexte de paiement

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

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

Cet objet :

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

Montant de l'argent

Le modèle AmountOfMoney fournit des informations sur le montant du paiement, consistant en un montant exprimé en type long et la devise spécifiée par currencyCode.

Notez que le montant inclut les fractions de devise. L'objet ci-dessous équivaut à 1 EUR.

Voir l'exemple ci-dessous :

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

Moyen de paiement de Base

Le modèle BasicPaymentProduct représente un moyen de paiementt primaire. Il 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 la méthode de paiement de ce produit.
• Deux champs qui indiquent le montant minimal et maximal requis pour payer avec ce moyen de paiement.
• Un champ indiquant si notre plateforme peut stocker les données de paiement sous forme de compte enregistré 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 la redirection vers un tiers.
• Une liste de comptes enregistrés précédemment pour ce moyen de paiement.
• Affiche des indices pour rendre le BasicPaymentProduct correctement, contenant :
  • Un index indiquant à quelle position le moyen de paiement appartient dans une liste de moyens de paiement
  • Un label
  • Un logo
• Informations sur les instances de AccountOnFile liées.
• Deux champs contenant des informations spécifiques sur le produit 302 (Apple Pay) et 320 (Google Pay).

Moyen de paiement

La classe Moyen de paiement étend la BasicPaymentProduct et complète le modèle avec la liste PaymentProductField. Lorsqu'un client sélectionne un élément de paiement ou un compte enregistré, il doit fournir des informations supplémentaires telles qu'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.

Pour récupérer des instances de PaymentProduct, utilisez l'extrait de code suivant :

BasicPaymentProductsResponseListener listener = BasicPaymentProductsResponseListener(
onSuccess: (paymentProducts) {
  	// Permettre au client de sélectionner un élément de paiement et un
  	// compte facultatif sur fichier à partir de la liste des produits
  	// de paiement représentés par paymentProducts.
},
onError: (apiError) {
  	// Indiquer qu'une erreur s'est produite.
},
onException: (throwable) {
  	// Indiquer qu'une erreur s'est produite.
}
);

await session.getBasicPaymentProducts(
request: BasicPaymentProductsRequest(paymentContext: context),
listener: listener
);

Champ de moyen de paiement

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

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

Le modèle inclut 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 de masquage et de démasquage de la valeur par le biais du StringFormatter intégré.

L'extrait de code ci-dessous montre comment récupérer le champ avec l'identifiant "cvv" à partir d'un moyen de paiement.  

PaymentProductField? field = paymentProduct.getPaymentProductFieldById("cvv");

if (field != null) {
    bool isRequired = field.dataRestrictions.isRequired;
    bool? obfuscate = field.displayHints?.obfuscate;
    field.validateValue("123");
    bool validValue = field.errorMessageIds.isEmpty;
}

Dans ce processus, nous :

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

Compte enregistré

Le AccountOnFile représente des informations sur un compte enregistré pour un moyen de paiement particulier. Il inclut :

• Un identifiant pour le compte enregistré.
• Un identifiant pour le moyen de paiement correspondant.
• Une collection de paires clé-valeur stockées comme partie du compte enregistré.
• Indices d'affichage contenant des informations sur la façon de rendre le compte enregistré.
• Une méthode qui produit un label décrivant le compte enregistré.

Récupérez les instances de AccountOnFile sous forme d'instances de BasicPaymentProduct en utilisant le code suivant :

AccountOnFile? getSelectedAccountOnFile(BasicPaymentProduct paymentProduct, String accountOnFileId) {
for(AccountOnFile aof in paymentProduct.accountsOnFile) {
if (aof.id == accountOnFileId) {
    return aof;
  }	
}
return null;
}

Indications d'affichage

Les Indications d'affichage sont des objets contenant des indices, répartis en trois types :

• PaymentProductDisplayHints : Les informations les plus importantes concernant BasicPaymentProduct, c'est-à-dire un nom et un logo. Une propriété supplémentaire est displayOrderwhich qui indique l'ordre d'affichage approprié selon l'index de l'ordre par rapport aux autres BasicPaymentProducts. Utilisez-les pour afficher la liste de sélection BasicPaymentProduct.
• AccountOnFileDisplayHints : La liste contenant les paires clé-valeur de ProductFields et le masque correspondant à appliquer (par exemple, des astérisques) à la valeur correspondante de AccountOnFile.
• PaymentProductFieldDisplayHints : Définit la manière d'afficher PaymentProductFields. En plus du nom et du placeholder, il contient PreferredInputType, en fonction de laquelle vous pouvez choisir :
  • Le type approprié de clavier à utiliser.
  • Si l'élément doit toujours être affiché en tant que AlwaysShow.
  • Si la valeur Obfuscate doit être obfusquée, ainsi que la valeur de Mask – une référence au ToolTip et au FormElement assignés.

Tooltip

Tooltip facilite la saisie des données. Elle peut être disponible dans les indications d'affichage pour un PaymentProductField. Elle peut contenir un texte d'explication ou un graphique, c'est-à-dire une photo d'une carte avec un CVV obfusqué.

Élément de formulaire

Une description simplifiée de l'élément visuel vous indiquant de l'utiliser de manière appropriée soit en tant que texte, liste, devise, date ou booléen.

Requête de paiement

Cette classe englobe la relation entre le PaymentProduct sélectionné, le AccountOnFile et les valeurs saisies. Elle vous permet d'extraire facilement des 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.

Requête de paiement préparée

L'instance de la classe PreparePaymentRequest est le résultat du chiffrement d'une requête à l'aide d'une instance de Session. Elle a deux propriétés, encryptedFields et encodedClientMetaInfo – les chaînes qui doivent être envoyées à notre plateforme. 

Consultez le chapitre dédié au chiffrement pour plus d'informations.

Réponse d'erreur

Si un appel API a échoué en raison d'une erreur liée à l'API, l'objet ErrorResponse contiendra plus d'informations sur l'erreur. Il contient un message, un ApiError facultatif et un Throwable facultatif.

Erreur de l'API

ApiError contient un identifiant d'erreur et une liste facultative d'erreurs API qui peuvent être utilisées pour aider à déterminer l'erreur exacte qui s'est produite.

Fonctionnalités supplémentaires

Le SDK a beaucoup plus à offrir. Consultez les fonctionnalités suivantes, car elles vous aideront à créer la solution parfaite.

• Chiffrer les données sensibles
• Valider les données
• Appliquer la vérification IIN
• Mettre en œuvre des paiements natifs
• Utiliser la logging

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/transfer ressemble à ceci :

Vous n'avez pas besoin de faire toutes ces étapes par vous-même. Grâce au SDK, vos actions sont simplifiées :

1. Lorsque votre client a complété toutes les informations de paiement requises et confirme le paiement, créez l'objet PaymentRequest, assignez-lui le PaymentProduct sélectionné et remplissez-le avec les valeurs saisies.
2. Validez le PaymentRequest créé en utilisant la méthode validate.
3. Si aucune erreur de validation n'est détectée, utilisez un objet Session et appelez preparePaymentRequest. Cela effectuera tout le processus de chiffrement pour vous et retournera 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 CreatePaymentmethod dans le champ encryptedCustomerInput du corps de la requête.
6. Vous envoyez le résultat de la transaction à l'application cliente.

L'algorithme utilisé est RSA-OAEP avec un encodage A256CBC-HS512. Bien qu'il soit possible de mettre en œuvre un chiffrement personnalisé, nous recommandons d'utiliser la fonctionnalité de chiffrement du SDK pour une sécurité optimale. Des données mal chiffrées peuvent entraîner des opérations incorrectes. De plus les données chiffrées ne sont pas vérifiées. 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 objet PaymentProductField possède un objet DataRestrictions. L'objet DataRestrictions contient les restrictions à appliquer et permet de valider si les valeurs saisies répondent aux restrictions. En plus d'une liste de validateurs, il possède une propriété isRequired indiquant si le champ est obligatoire ou non.

Vous pouvez valider la saisie d'un champ via la méthode validate de l'objet PaymentRequest. En cas d'erreurs, l'objet Errors permet d'afficher une liste d'erreurs.

Les validateurs possibles sont les suivants :

• Expiration Date : Vérifie si la date d'expiration de la carte saisie n'est pas antérieure à la date actuelle et si elle n'est ultérieure à la date actuelle plus 25 ans.
• Email Address : Vérifie le format de l'adresse e-mail fournie par le client.
• Fixed List : Vérifie si la valeur saisie figure sur la liste des valeurs possibles.
• IBAN : Valide l'IBAN fourni par le client.
• Length : Vérifie si la valeur saisie est plus longue que la valeur minimale mais pas plus longue que la valeur maximale.
• Luhn : La formule de somme de contrôle utilisée pour valider une variété de numéros d'identification, tels que les numéros de carte de crédit.
• Range : Vérifie si la valeur est supérieure à la valeur minimale et si elle n'est pas supérieure à la valeur maximale.
• Regex : Valide que la valeur saisie correspond bien à l'expression régulière.
• TermsAndConditions : Le validateur booléen pour le champ d'acceptation des termes et conditions.

Chaque validateur renvoie une erreur appropriée, indiquant un champ qui ne respecte pas les 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 numéro d'identification de l'émetteur (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 : Le moyen de paiement principal associé à cet IIN.
• countryCode : Le code pays du moyen de paiement principal associé à cet IIN.
• status : Type de IinStatus qui indique le résultat de la vérification IIN. Les statuts possibles sont :
  • SUPPORTED : L'IIN est associé à un moyen de paiement disponible sur notre plateforme.
  • UNKNOWN : L'IIN n'est pas reconnu.
  • NOT_ENOUGH_DIGITS : Moins de six chiffres ont été fournis.
  • EXISTING_BUT_NOT_ALLOWED : L'IIN est reconnu, mais ne peut pas être utilisé pour le paiement actuel.
• isAllowedInContext : Indique s'il est autorisé d'effectuer un paiement avec le moyen de paiement principal en fonction du PaymentContext.
• coBrands : Une liste d'instances de IinDetail, qui représente les co-marques pour l'IIN actuel.
• cardType : Type de CardType tel que catégorisé par la méthode de paiement. Les types possibles sont :
  • Crédit
  • Débit
  • Prépayé

Il est possible qu'une seule carte de crédit ait plusieurs marques associées et soit ainsi "co-marqué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 de niveau supérieur de la réponse IinDetailsResponse. Si le co-marquage 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 de niveau supérieur. 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.

void doIINLookup() async {
String unmasked = await paymentRequest.getUnmaskedValue("cardNumber");

IinLookupResponseListener listener = IinLookupResponseListener(
onSuccess: (response) {
  if (response.status == IinStatus.supported) {
    if (!response.coBrands.isEmpty) {
      if (!self.isSelectedPaymentProduct(response.coBrands) {
        switchToPaymentProduct(response);
      }

       // La législation de l'UE exige que, dans le cas
             // d'une carte avec plusieurs marques, un client puisse
             // choisir avec quelle marque il veut effectuer le paiement.
      self.showCoBrandNotification();
    } else if (response.paymentProductId != paymentItemIdentifier) {
                self.switchToPaymentProduct(response);
           }
   	} else {
            // Gérer les autres codes de statut.
        }
},
onError: (apiError) {
  	// Indiquer qu'une erreur s'est produite.
},
onException: (throwable) {
  	// Indiquer qu'une erreur s'est produite.
}
    );
}

bool isSelectedPaymentProduct(List coBrands) {
    IinDetails? SelectedCoBrand = coBrands.firstWhereOrNull((coBrand) => coBrand.paymentProductId == paymentItemIdentifier);
    return selectedCoBrand != null;
}

func switchToPaymentProduct(_ response: IINDetailsResponse) {
    if (response.allowedInContext && response.paymentProductId != null) {
        // Passer au moyen de paiement qui est effectivement dans
        // la réponse des détails Iin de niveau supérieur.
        paymentItemIdentifier = response.paymentProductId;
    }
    else {
        // Fournir au client un message d'erreur indiquant que le
        // numéro de carte de crédit qu'il saisit ne peut actuellement pas être utilisé pour payer.
        // Montrer au client qu'il peut choisir une autre marque pour payer.
    }
}

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

Mettre en œuvre les paiements natifs

Le SDK prend en charge les paiements natifs pour les appareils mobiles incluant Google Pay pour Android et Apple Pay pour iOS.

Si une méthode de paiement est éligible au paiement natif, le SDK vérifie automatiquement la capacité de l'appareil à effectuer ce paiement natif. Si l'appareil ne remplit pas les conditions requises alors la méthode de paiement est masquée. Grâce à cette mécanique, vous n'avez pas à vous soucier de vérifier vous-même la faisabilité du paiement natif.

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

Utiliser la Logging

Dans certains scénarios, activer la Logging des requêtes et des réponses pour la communication avec notre plateforme peut être bénéfique.

Activez la Logging en définissant loggingEnabled sur true dans le constructeur de Session pendant le développement :

Session session = Session("clientSessionId", "customerId", "clientUrl", "assetUrl", loggingEnabled: true);