Aller au contenu principal

SDK

Pour un usage web, l'approche recommandée est d'utiliser le SDK Unico, pour les raisons suivantes :

  • Sécurité renforcée ;
  • Expérience intégrée à votre flux ;
  • Taux de conversion plus élevé lors de l'utilisation du SDK ;
  • Implémentation plus simple.
avertissement

L'utilisation d'intégrations qui ne respectent pas les standards établis dans cette documentation peut entraîner des interruptions inattendues du fonctionnement du système, qui ne seront ni couvertes ni prises en charge par Vérification sans carte présente.

Par exemple : implémenter le Unico par iFrame au sein d'une webview, implémenter l'iFrame via une balise HTML, etc.

Recommandations générales​

Pour optimiser la performance de votre opération, améliorer les taux de conversion et offrir une expérience utilisateur plus fluide, il est obligatoire d'implémenter le SDK Unico en mode plein écran dans votre application.

Comment démarrer​

Pour utiliser Vérification sans carte présente via le SDK Vérification sans carte présente, la première étape consiste à enregistrer les domaines qui seront utilisés comme hôtes pour afficher l'expérience du parcours utilisateur.

danger

Informez le responsable de votre projet d'intégration ou l'équipe de support Unico pour effectuer cette configuration.

Pour commencer à utiliser le SDK, nous devons d'abord procéder à l'installation du SDK web Unico :

npm install idpay-b2b-sdk
conseil

Lors de l'installation du package SDK Unico, déployez sans spécifier la version que vous utilisez, afin que votre gestionnaire de dépendances mette toujours à jour les versions mineures et les correctifs vers la dernière version.

Pour consulter les versions précédentes, rendez-vous sur npmjs.com/package/idpay-b2b-sdk.

Méthodes disponibles​

init(options)​

Cette méthode permet d'initialiser le SDK, indépendamment d'un identifiant de transaction, rendant l'expérience de l'utilisateur final plus fluide. En effet, lorsque l'identifiant de transaction et le token deviennent disponibles, l'application aura déjà été préchargée grâce à cette méthode. Si cette méthode n'est pas appelée directement par l'application, l'utilisateur final subira un long temps de chargement lors de la première ouverture du SDK.

Paramètres :

  • options — reçoit un objet avec des propriétés de configuration :
    • type — le type de flux qui sera initialisé. Actuellement, nous proposons le type IFRAME. Pour les nouvelles applications, nous recommandons d'utiliser le type IFRAME, qui rend l'expérience de l'utilisateur final beaucoup plus fluide et avec moins de friction, car il évite d'avoir à quitter l'écran de checkout, et l'expérience peut être préchargée.
import { IDPaySDK } from "idpay-b2b-sdk";

IDPaySDK.init({
  type: 'IFRAME',
  env: 'uat' // Only needed for the test environment.
});

open({ transactionId, token, onFinish? })​

Cette méthode ouvre l'expérience Vérification sans carte présente selon le type de flux choisi précédemment dans la fonction d'initialisation. Pour le flux REDIRECT, cette fonction effectue une simple redirection vers la route du flux de capture Vérification sans carte présente. Pour le flux IFRAME, cette fonction affiche l'iframe préchargée et démarre le flux de messagerie entre la page du client et l'expérience Vérification sans carte présente.

Paramètres :

  • options — reçoit un objet avec des propriétés de configuration :
    • transactionId — reçoit l'identifiant de la transaction créée. Cet identifiant est important pour obtenir les détails de la transaction et terminer correctement le flux (il peut être obtenu lors de la création de la transaction via l'API).
    • token — reçoit le token de la transaction créée. Ce token est important pour authentifier la transaction et garantir que seuls les domaines autorisés l'utilisent (il peut être obtenu lors de la création de la transaction via l'API).
    • onFinish(transaction, type) (optionnel) — reçoit une fonction de callback qui sera exécutée à la fin du flux de capture Vérification sans carte présente, en transmettant deux arguments : l'objet transaction ({ captureConcluded, concluded, id }), et le type de réponse — FINISH pour les cas où le flux s'est terminé avec succès, ou ERROR pour les cas où le flux a été interrompu par une erreur. En cas d'erreur dans le flux, le statut de la transaction ne sera pas modifié, et un callback via webhook, s'il est configuré, ne sera pas déclenché.
const transactionId = '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf';
const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c';

const transaction = {
  id: '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf',
  concluded: true,
  captureConcluded: true
};

const onFinish = (transaction, type) => {
  console.log('response', transaction, type);
}

IDPaySDK.open({
  transactionId,
  token,
  onFinish
});

// You can also close the SDK explicitly using the method below
IDPaySDK.close();

Sécurité​

Après une analyse approfondie des besoins et des défis auxquels nous sommes confrontés, nous avons décidé d'adopter une solution basée sur des iFrames avec des tokens d'authentification plutôt que d'implémenter une Content Security Policy (CSP). Cette décision a été motivée par plusieurs considérations liées à la sécurité et à la flexibilité requise pour répondre aux demandes de nos clients.

Contexte et défis liés au CSP​

La Content Security Policy (CSP) est un outil puissant pour protéger les applications web contre différents types d'attaques, tels que le Cross-Site Scripting (XSS) et l'injection de code. Cependant, lors de la configuration d'une politique CSP, il est nécessaire de définir une liste stricte de domaines de confiance. Cette approche fonctionne bien lorsque les domaines sont fixes et prévisibles. Cependant, pour nos clients qui utilisent souvent des domaines dynamiques et variables, cette configuration rigide présente des défis importants.

Vulnérabilité liée aux domaines dynamiques​

Les domaines dynamiques posent un risque de sécurité substantiel lors de l'utilisation du CSP. Lorsqu'un client possède des domaines qui changent fréquemment ou qui sont créés dynamiquement, il serait nécessaire de mettre à jour constamment la politique CSP pour inclure ces nouveaux domaines. Cela augmente non seulement l'effort de maintenance, mais expose également les domaines auxquels s'applique la politique CSP. Chaque domaine ajouté à la politique CSP constitue potentiellement un point de vulnérabilité s'il n'est pas correctement géré.

Solution avec iFrame et token d'authentification​

Pour atténuer ces risques et répondre à la flexibilité requise par nos clients, nous avons choisi d'utiliser des iFrames combinées à des tokens d'authentification. Cette solution offre une couche de sécurité supplémentaire et élimine le besoin d'exposer ou de gérer une liste étendue et dynamique de domaines.

Comment cela fonctionne​

  • Authentification sécurisée : chaque iframe est chargée avec un token d'authentification unique pour chaque transaction, garantissant que seuls les utilisateurs autorisés peuvent accéder au contenu. Ce token est vérifié en temps réel, offrant une couche de sécurité et de contrôle supplémentaire.
  • Isolation du contenu : l'utilisation d'iFrames permet d'isoler le contenu dans un contexte séparé, réduisant le risque d'interférence entre différentes origines et atténuant les attaques potentielles.
  • Flexibilité pour les domaines dynamiques : en ne s'appuyant pas sur une politique CSP statique, notre solution s'adapte facilement aux domaines dynamiques des clients, sans nécessiter de mises à jour constantes des politiques de sécurité.
Dernière mise à jour le