SDK JavaScript

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

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

• 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 des images pour offrir des informations supplémentaires sur les moyens de paiement.
• Le formatage convivial 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 exemple simule l'interface utilisateur pour tout le processus de paiement basé sur l'interaction entre l'application et notre plateforme. Trouvez le code source du SDK et l'application exemple sur GitHub, y compris les instructions d'installation.

Une fois que vous êtes prêt, lisez les chapitres suivants sur la façon 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 leur utilisation, nous avons préparé un package ci-dessous pour une intégration rapide.

NPM

Pour tirer pleinement parti de ce SDK, assurez-vous de répondre à ces exigences :

• Node v12+
• NPM v6+

Depuis la racine du projet, exécutez npm ci pour installer les dépendances requises.

Ensuite, exécutez npm run build. En conséquence, /dist/ (un dossier distribuable) sera créé, contenant à la fois une version originale et une version minifiée de

• onnlinepaymentssdk.noEncrypt.js : Une source SDK entièrement regroupée sans les composants de chiffrement (par défaut)
• onlinepaymentsdk.js : Une source SDK entièrement regroupée avec les composants de chiffrement

Après l'intégration réussie du SDK à votre projet, vous pouvez procéder 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 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 la session

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 API Client et notre API Serveur.

Étant donné que le client initie le paiement dans son application, l'application Client requête à l'application Serveur de créer une session. Lorsqu'une application Serveur reçoit une requête, elle peut créer une session via Create  Session à partir 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.direct.worldline-solutions.com/",
    "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 côté application Client.

2. Recevoir les méthodes de paiement possibles

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

Jetez un coup d'œil à l'exemple de code montrant comment obtenir la liste des BasicPaymentItems avec l'objet Session.

var paymentDetails = 
{ 
  "totalAmount" : 16195,
  "countryCode" : "NL", 
  "locale" : "nl_NL", 
  "isRecurring" : false,
  "currency" : "EUR"
}; 

session.getBasicPaymentItems(paymentDetails, true).then(function (paymentItems) { 
	
    // Permettre au client de sélectionner un élément de paiement et un compte facultatif dans la liste des éléments de paiement
    // représentée par paymentItems.

 }, function() { 
    // Indiquer qu'une erreur s'est produite. 
});

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. Utilisez notre application exemple pratique comme base pour votre propre implémentation.

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

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

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 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 les 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 de les demander à 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 encore devoir fournir certaines données (par exemple, le CVC).

4. Valider les données fournies

Votre application doit maintenant valider les données que vos clients saisissent 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 infobulles, qui ont 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 possède une propriété tokenize utilisée pour indiquer si l'application doit stocker les informations d'identification du client pour les paiements récurrents.
Utilisez l'exemple de code suivant pour les demandes de paiement sans account on file (compte enregistré) :

var paymentRequest = session.getPaymentRequest();
paymentRequest.setPaymentProduct(paymentProduct); 
paymentRequest.setTokenize(false);

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

paymentRequest.setAccountOnFile(accountOnFile);     

Une fois que vous configurez 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", "1245 1254 4575 45"); 
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 au client. Pour plus d'informations, lisez le chapitre dédié.

if (paymentRequest.isValid()) { 
     // La requête de paiement est valide, vous pouvez la chiffrer et l'envoyer à notre plateforme via votre serveur.
}
else { 	
    // Informez l'utilisateur que certains champs contiennent des données invalides.
   var errors = paymentRequest.getErrorMessageIds(); 
}

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 Encryptor pour chiffrer une requête :

encryptor = session.getEncryptor(); 
encryptor.encrypt(paymentRequest).then(function(encryptedString) {
    // Soumettez les informations contenues dans la chaîne chiffrée
    // à notre plateforme via votre serveur.
}, function(errors) { 	
    // Indiquer qu'une erreur s'est produite.
});

6. Finaliser la transaction

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

Enfin, vous devez transmettre les informations à 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 :

• C2sCommunicator
• Session
• PaymentDetails
• BasicPaymentItem interface
  • BasicPaymentProduct
  • PaymentProduct
    • PaymentProductField
• AccountOnFile
• DisplayHints
  • ToolTips
  • FormElement
• PaymentRequest
• Util
• Responses

C2sCommunicator

Ceci est le service de communication principal. 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 :

• Encapsule C2sCommunicator qui implémente 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 :

• clientSessionId
• custommerId
• clientApiUrl
• assetUrl

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

La classe C2sCommunicatorConfiguration dispose de méthodes statiques pour initialiser Session :

// Note : une réponse réussie de Create Session peut être utilisée directement en entrée 
var session = new directsdk.Session(
{ 
clientSessionId : "47e9dc332ca24273818be2a46072e006", 
customerId : "9991-0d93d6a0e18443bd871c89ec6d38a873", 
clientApiUrl : "https://clientapi.com", 
assetUrl : https://asset.com
});

Assurez-vous de déterminer si l'application fonctionne en production et spécifiez 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 métadonnées de l'appareil 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. Transmettez cette valeur au SDK Client pour vous assurer que le logiciel Client se connecte au bon centre de données. string assetUrl : L'URL de base spécifique au centre de données pour les ressources.

PaymentDetails

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

• totalAmount : montant total
• currency : devise
• countryCode : code pays
• isRecurring : Une indication de si le paiement est un paiement unique ou Card On File.
• locale : langue

Ce objet :

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

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

"paymentDetails": {
    "amount": 100,
    "currencyCode": "EUR",
    "countryCode" : "GB", 
    "locale" : "en_GB", 
    "isRecurring" : false
}

Interface BasicPaymentItem

L'interface principale de BasicPaymentItem est principalement responsable de l'identification et de la présentation visuelle facile de l'élément de paiement. Elle dispose de :

• Un identifiant
• Une liste de DisplayHints qui contient l'annonce visuelle (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 liées de comptes enregistrés.

BasicPaymentProduct

L'objet principal d'un moyen de paiement. Il contient une liste de méthodes de paiement disponibles. Le client peut sélectionner une méthode dans cette liste. Chaque instance contient :

• Un identifiant.
• Un champ indiquant la méthode de paiement de ce produit.
• Deux champs indiquant 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 comme un compte enregistré pour des paiements ultérieurs.
• Un champ indiquant si la méthode permet des Card On File.
• Un champ indiquant si la méthode de paiement utilise une redirection vers un tiers.
• Une liste de comptes enregistrés précédemment pour ce moyen de paiement.
• Des éléments pour le rendu du BasicPaymentProduct approprié, contenant :
  • Un index indiquant à quelle position le moyen de paiement appartient dans une liste de moyens de paiement
  • Un label
  • Un logo

Moyen de paiement

Il étend la classe BasicPaymentProduct et implémente l'interface PaymentItem qui complète le modèle avec la liste de PaymentProductField. 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 des instances de PaymentProduct :

var paymentProductId = "xyz"
 
// Créer les PaymentDetails 
 
var paymentDetails = 
{ 
   "totalAmount" : 16195,
   "countryCode" : "NL", 
   "locale" : "nl_NL", 
   "isRecurring" : false,
   "currency" : "EUR" 
};

// Obtenez le moyen de paiement sélectionné 

session.getPaymentProduct(paymentProductId,paymentDetails).then(function(paymentProduct) 
{ 
		// Créez une requête de paiement en utilisant le moyen de paiement
// représenté par paymentProduct.
}, function() 
{ 
    // Indiquez qu'une erreur est survenue.
});
 
// Obtenez tous les BasicPaymentItems disponibles pour le contexte de paiement 
 
session.getBasicPaymentItems(paymentDetails, true).then(function (basicPaymentItems) 
{
 	// Permettez au client de sélectionner un élément de paiement et un compte
// optionnel enregistré à partir de la liste des éléments de paiement
// représentés par paymentItems.

}, function() 
{ 
     // Indiquez qu'une erreur est survenue.
});

PaymentProductField

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

• Un identifiant
• Un 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 possède 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 retourne des ValidationErrorMessages et des méthodes pour masquer et déconstruire les valeurs au moyen 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 :

• 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 vérifier si la valeur fournie est valide.

var cvvField = paymentProduct.paymentProductFieldById["cvv"]; 
var isRequired = cvvField.dataRestrictions.isRequired;
var obfuscate = cvvField.displayHints.obfuscate;
var isValid = cvvField.isValid("123");
var validationErrors = cvvField.getErrorCodes("123");

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 stockées en tant que partie du compte enregistré.
• Des indications concernant la façon d'afficher le compte enregistré.
• Une méthode qui produit une étiquette décrivant le compte enregistré.

Récupérez les instances de AccountOnFile sous forme d'instances de BasicPaymentProduct comme suit :

// Ceci est un tableau d'objets AccountOnFile 
var accountsOnFile = basicPaymentItems.accountsOnFile; 
// Cela renvoie l'objet Visa BasicPaymentProduct dans cet objet PaymentProducts s'il existe. 
var paymentProduct = basicPaymentItems.paymentProductById["1"];

DisplayHints

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

• PaymentProductDisplayHints : Les informations les plus importantes sur le PaymentProduct, c'est-à-dire un nom et un logo. Une propriété supplémentaire est displayOrder qui indique l'ordre d'affichage approprié en relation avec d'autres PaymentProduct utilisés par BasicPaymentProducts. Utilisez-les pour afficher la liste de sélection de PaymentProduct.
• AccountOnFileDisplayHints : 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.
• PaymentProductFieldsDisplayHints : Définit la manière d'afficher les PaymentProductFields. Outre le nom et l'indication, il contient PreferredInputType, sur la base duquel vous pouvez choisir :
  • Le type de clavier approprié que vous devez utiliser.
  • Si l'élément doit toujours être affiché : AlwaysShow.
  • Si la valeur doit être obfusquée, ainsi que la valeur du masque.

ToolTips

ToolTips facilitent la saisie de données. Vous pouvez ajouter un objet ToolTip dans les indications d'affichage pour les PaymentProductFields. Il peut contenir un texte explicatif ou un graphique, par exemple une photo d'une carte avec un CVV obfusqué.

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 encapsule 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 pour valider les données saisies. Consultez le chapitre sur le chiffrement dédié pour plus d'informations.

Util

Une classe intégrée contenant des outils que vous pouvez utiliser pour faciliter votre travail avec le code, tels que

• getMetadata : Renvoie des métadonnées telles que screenSize, platformIdentifier, sdkIdentifier et sdkCreator.
• collectDeviceInformation : Collecte les informations les plus importantes de l'appareil: timezoneOffsetUtcMinutes, locale et browserData.
• base64Encode : Encode en base64.
• filterOutProductThatAreNotSupportedInThisBrowser : Filtre les méthodes de paiement disponibles pour le client.

Responses

• IinDetailsResponse : La réponse pour la vérification du numéro d'identification de l'émetteur.
• PublicKeyResponse : API Client que vous utilisez pour récupérer une clé publique spécifique à la transaction depuis notre serveur. Utilisez-la pour chiffrer des données sensibles, c'est-à-dire des détails de carte. Cet objet retourne automatiquement une clé publique déjà décryptée depuis notre API.

Fonctionnalités supplémentaires

Le SDK offre beaucoup plus. 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
• Configurer la langue et le format de l'application
• 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.-à-d. numéros de carte, date d'expiration, 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 remplissent toutes les informations de paiement requises et confirment le paiement, créez l'objet PaymentRequest, assignez-lui le PaymentProduct sélectionné et remplissez-le avec les valeurs saisies.
2. Validez l'objet PaymentRequest créé en utilisant la méthode Validate.
3. S'il n'y a pas d'erreurs de validation, utilisez un objet Encryptor et appelez la méthode Encrypt. Elle effectuera tout le 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 de la requête API Serveur encryptedCustomerInput.
6. Vous retournez le résultat de la transaction à l'application client.

L'objet encryptor encapsule le JOSEEncryptor. Il est possible d'utiliser directement le JOSEEncryptor, mais vous manquerez les fonctionnalités d'assistance que l'objet encryptor offre. Nous ne garantissons pas le bon fonctionnement en cas de données mal chiffrées. Notez que nous ne pouvons pas vérifier la présence d'erreurs dans les données chiffrées. Par conséquent, vous devez vous assurer que toutes les opérations précédentes ont été correctement effectuées.

Si vous souhaitez utiliser JOSEEncryptor directement, vous devez fournir les données dans le JSON suivant :

{ 
    "clientSessionId": "9991-89034758982340982334234234", 
    "nonce": "067e6162-3b6f-4ae2-a171-2470b63dff00",
    "paymentProductId": 1, 
    "accountOnFileId": 3, 
    "tokenize": true, 
    "paymentValues": [
        { "key": "cvv", "value": "159" }, 
        { "key": "expiryDate", "value": "1115" }, 
        { "key": "cardNumber", "value": "4242424242424242" } 
    ]
}

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 dispose également d'une propriété isRequired indiquant si des restrictions données sont requises ou non.

Vous pouvez valider une saisie particulière aussi facilement que 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 plage de vingt-cinq ans à l'avance.
• 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 minimum et si elle n'est pas plus longue que la valeur maximum.
• Luhn : La formule de somme de contrôle utilisée pour valider divers numéros d'identification, tels que les numéros de cartes de crédit.
• Plage : 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 à 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 renvoie 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 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 a les propriétés suivantes :

• paymentProductId : Le moyen de paiement principal associé à cet IIN.
• countryCode : Le code du 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 il ne peut pas être utilisé pour le paiement actuel.
• isAllowedInContext : Indique s'il est autorisé de faire un paiement avec le moyen de paiement principal basé sur le PaymentContext.
• coBrands : Une liste d'instances de IinDetail, qui montrent les co-badges 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 de niveau supérieur de IinDetailsResponse. Si le co-badging 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 laisser les clients choisir leur marque préférée. S'il y a seulement un moyen de paiement associé à la carte de crédit, la liste des détails IIN est vide.

var paymentDetails = { 
"totalAmount" : 16195, // en centimes 
"countryCode" : "NL", 
"locale": "nl_NL", 
"isRecurring" : false, // définir si récurrent 
"currency": "EUR" // définir la devise
}; 

var firstSixDigitsOfCreditcardNumber = "123456"; 

session.getIinDetails(firstSixDigitsOfCreditcardNumber,paymentDetails).then(function(iinDetailsResponse) { 

// La promesse a été remplie. 
}, 
function(errors) { 	
// La promesse a échoué, informer l'utilisateur de ce qui s'est passé.
});

Configurer la langue et le format de l'application

Notre SDK offre des libellés localisés pour toutes les entités que vous demandez via l'API Client. Vous pouvez atteindre cela en définissant le champ "locale" de l'objet paymentDetails à la valeur correcte lors d'un appel à getPaymentProducts. Vous pouvez changer de langue à tout moment pendant le flux de paiement en renvoyant la requête.

Utiliser l'application de démonstration

L'application exemple illustre les possibilités du SDK et les services offerts par notre plateforme. Retrouvez le code source sur GitHub. Vous pouvez utiliser ce code comme base pour votre application. L'application exemple se compose de quatre écrans :

• Le premier écran requête les informations nécessaires pour communiquer avec l'API Client et récupérer une liste de moyen de paiement. Cet écran ne devrait pas faire partie d'une application réelle dans la boutique d'applications. Nous le fournissons pour illustrer quelles informations sont nécessaires pour initialiser une instance de Session
• Le deuxième écran est un écran de sélection de moyen de paiement généré dynamiquement. Basé sur les informations fournies dans le premier écran, l'application affiche une liste des moyens de paiement disponibles et des comptes enregistrés. Cet écran ou un écran similaire ferait généralement partie d'une application réelle. Voir plus de détails ci-dessous.
• Après la sélection d'un moyen de paiement, l'application affiche le troisième écran et obtient les entrées du client. Le client ne peut confirmer le paiement que lorsque le SDK a validé les entrées. Également, cet écran ou un écran similaire ferait partie d'une application réelle. Voir plus de détails ci-dessous.
• Le quatrième écran indique que le SDK a traité avec succès le paiement initié. Cet écran ne devrait pas faire partie d'une application réelle.

Écran de sélection de moyen de paiement

L'écran de sélection de moyen de paiement fournit un exemple pour l'un des deux écrans qui apparaîtront dans la plupart des applications utilisant le SDK. Il montre une liste d'éléments de paiement disponibles et de comptes enregistrés. Pour chaque élément de paiement / compte enregistré, il affiche un nom localisé ou une courte description des informations du compte enregistré. Si un logo est disponible pour un élément de paiement, l'écran l'affichera.

L'écran contient une partie d'une liste d'éléments de paiement disponibles, générée à partir des informations contenues dans une instance de BasicPaymentItems.

Validation de formulaire

L'application exemple utilise le SDK pour valider les informations fournies par le client lorsqu'il appuie sur le bouton Payer. Si les données fournies sont invalides, des messages d'erreur sont affichés sous les valeurs incorrectes.

Informations supplémentaires

Certains champs de moyens de paiement peuvent nécessiter des explications supplémentaires. Le bouton d'information à côté du champ de texte pour le code CVV indiqué ci-dessous signale 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 exemple montre également l'utilisation de la vérification de l'IIN décrite ci-dessus. Pour chacun des moyen de paiement basés sur la carte, une vérification de l'IIN est effectuée dès que le client a saisi 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 à droite du champ de texte. Si l'IIN est associé à un autre moyen de paiement, les champs de saisie sont automatiquement remplacés par ceux du nouveau moyen de paiement.

La capture d'écran montre également comment les cartes co-badgées peuvent être affichées. Le logo et le nom des co-badges du moyen de paiement sont récupérés en effectuant des appels spécifiques pour eux.