Dernière mise à jour 19/11/2015

2. Procédures générales et paramètres de sécurité

Les procédures générales et contrôles de sécurité sont valides pour toutes les demandes DirectLink: nouvelles requêtes de commande, requêtes de maintenance et interrogations directes (direct queries).

2.1 Utilisateur API

Un utilisateur API (Application Program Interface) est nécessaire pour présenter des demandes DirectLink.

En général, cet utilisateur est spécifiquement conçu pour qu’une application puisse présenter des demandes automatiques à la plateforme de paiement.

Vous pouvez créer un utilisateur API dans votre compte Ingenico via « Configuration » > « Users » (Utilisateurs). Sélectionnez « New User » (Nouvel utilisateur) et remplissez les champs obligatoires.

Pour que le nouvel utilisateur soit un utilisateur API, assurez-vous de cocher la case « Special user for API (no access to admin.) » (Utilisateur spécial API (aucun accès admin.)).

Creation of an API user 

Bien que plusieurs profils d’utilisateur soient disponibles pour l’utilisateur API, nous vous recommandons vivement de configurer cet utilisateur sur le profil « Admin » (Administrateur).
Si vous souhaitez limiter les droits de maintenance des transactions (remboursement, annulations, etc.), vous pourrez toujours modifier le profil utilisateur et le configurer sur « Encoder » (Encodeur), par exemple.

En cas de doute, nous vous recommandons de choisir le profil « Admin », autrement, accédez à Profils d'utilsateur (Gestionnaire des utilisateurs).

Le mot de passe d’un utilisateur API n’a pas besoin d’être modifié régulièrement. Ce qui est avantageux lorsque le mot de passe doit être codé en dur dans votre application. Nous vous recommandons néanmoins de changer de mot de passe de temps à autre.

Pour en savoir plus sur les types d’utilisateur et sur la façon de modifier le mot de passe de l’utilisateur API, accédez à Types d'utilisateur (Gestionnaire des utilisateurs).

2.2 Formulaire de requête

Pour les requêtes de nouvelle commande, les requêtes de maintenance et les interrogations directes (direct queries), le marchand doit envoyer des requêtes avec certains paramètres vers des URLs spécifiques. Les paramètres de paiement/maintenance/interrogation doivent être envoyés dans une demande POST comme suit:

PSPID=value1&USERID=value2&PSWD=value3&…

Le sous-type (subtype) indiquant le type de média dans le champ header “Content-Type entity” dans la requête POST doit être encodé en "application/x-www-form-url".

DirectLink fonctionne dans un mode “une requête-une réponse”, chaque paiement est traité individuellement. Notre système gère individuellement les requêtes de transaction via DirectLink et peut travailler simultanément (lorsque cette option est supportée techniquement), par exemple nous attendons la réponse de la banque avant de renvoyer une réponse XLM vers la requête.

2.3 Sécurité

Lorsque nous recevons des requêtes sur nos serveurs, nous vérifions le niveau de cryptage ainsi que l’adresse IP à partir de laquelle la requête a été envoyée.

2.3.1 Cryptage

DirectLink est construit sur un protocole de communication sécurisé et robuste. L’API DirectLink est un ensemble d’instructions soumises avec des requêtes HTTPS POST classiques.

Au niveau du serveur, nous utilisons un certificat délivré par Verisign. Le cryptage TLS garantit que ce sont effectivement nos serveurs avec lesquels vous communiquez et que vos données sont transmises sous une forme encryptée. Il n’est pas nécessaire d’utiliser un certificat client TLS.

Lorsque nous recevons une requête, nous vérifions le niveau de cryptage. Nous permettons aux marchands de se connecter à nous dans un seul mode https sécurisé en utilisant les protocoles TLS et nous recommandons fortement l’utilisation des versions les plus récentes et sécurisées, qui sont actuellement TLS 1.1 et 1.2.

Note: A l’heure où nous avons écrit cette documentation, nous supportions toujours SSL v3. Cependant, dû à certaines vulnérabilités, ce protocole est en train d’être progressivement décommissionné et ne sera bientôt plus supporté.

2.3.2 Adresse IP

Pour chaque requête, notre système vérifie l’adresse IP à partir de laquelle la requête a été envoyée afin de s’assurer que les requêtes ont bien été envoyées à partir du serveur du marchand. Dans le champ adresse IP de l’onglet "Contrôle de données et d’origine”, dans la section "Contrôles pour DirectLink" de la page Information technique de votre compte, vous devez entrer l’adresse IP ou le groupe d’adresse IP des serveurs qui envoient vos requêtes.

Si l’adresse IP à partir de laquelle la requête a été envoyée n’a pas été déclarée dans le champ d’adresse IP de l’onglet “Contrôle de données et origine”, à vérifier dans la section DirectLink de la page d’information technique de votre compte, vous recevrez le message d’erreur “unknown order/1/i”. L’adresse IP à partir de laquelle la requête a été envoyée sera également montrée dans le message d’erreur.

2.3.3 Signature SHA

La signature SHA est basée sur le principe même que le serveur du marchand génère une chaîne unique de caractères pour chaque commande, hachée avec les algorythmes SHA-1, SHA-256 u SHA-512. Le résultat de ce hachage nous est envoyé dans la requête de commande du marchand. Notre système reconstruit la signature afin de vérifier l’intégrité des données de commande qui nous ont été envoyées dans la requête.

Cette chaîne est construite en concaténant les valeurs des champs envoyés avec la commande (triés alphabétiquement, dans le format ‘paramètre=valeur’), avec chaque paramètre et valeur suivis d’une passphrase. La passphrase est définie dans l’Information Technique du marchand, dans l’onglet “Contrôle de données et origine”, dans la section “Contrôles pour DirectLink”. Pour la liste complete des paramètres à inclure dans le Digest SHA, veuillez cliquer ici. A noter que ces valeurs sont toutes sensibles à la casse lorsqu’elles sont assemblées pour former la chaîne avant le hachage!

Important
  • Tous les paramètres que vous envoyez (et qui apparaissent dans la Liste des Paramètes à inclure dans le calcul du SHA-IN), seront inclus dans la suite (string) à hacher.
  • Tous les noms de paramètres devraient être en MAJUSCULES (Afin d’éviter toute confusion) 
  • Les paramètres doivent être triés par ordre alphabétique
  • Les paramètres qui n’ont pas de valeur ne devraient PAS être inclus dans la suite (string) à hacher
  • Lorsque vous optez pour le transfert du compte de test en production en utilisant le lien dans votre compte, une passphrase SHA-IN aléatoire sera automatiquement configurée dans votre compte de production.
  • Par mesure de sécurité, nous vous invitons à utiliser des mots de passe SHA différents en TEST et PROD. Veuillez noter que si identiques dans les deux environnements, votre passphrase en TEST serait changée par notre système (vous en seriez bien entendu notifié).

Lorsque vous hachez la suite (string) composé par l’algorythme SHA, un résumé hexadécimal sera renvoyé. La longueur de ce résumé SHA est de 40 caractères pour le SHA-1, 64 pour le SHA-256 et 128 pour le SHA-512. Ce résultat devrait être envoyé à notre système dans votre requête de commande, en utilisant le champ “SHASign”.

Notre système recomposera lui-même la suite (string) SHA en se basant sur les paramètres reçus et comparera le résumé (digest) du marchand avec le résumé (digest) que nous avons généré.  Si le résultat n’est pas identique, la commande sera refuse. Ce contrôle garantit l’exactitude et l’intégrité des données de commande.

Vous pouvez tester votre signature SHA ici.

Exemple de calcul d’un SHA-1-IN avec les seuls paramètres de base

Paramètres (par ordre alphabétique)
AMOUNT: 15.00 -> 1500
CARDNO: 4111111111111111
CURRENCY: EUR
OPERATION: RES
ORDERID: 1234
PSPID: MyPSPID

SHA Passphrase (Dans "Information Technique"):
Mysecretsig1875!?

String à hacher
AMOUNT=1500Mysecretsig1875!?CARDNO=4111111111111111Mysecretsig1875!?CURRENCY=EURMysecretsig1875!?
OPERATION=RESMysecretsig1875!?ORDERID=1234Mysecretsig1875!?PSPID=MyPSPIDMysecretsig1875!?

Résumé de résultat (SHA-1)
2B459D4D3AF0C678695AE77EE5BF0C83CA6F0AD8

Si le signature SHA envoyé dans votre requête ne correspond pas au SHASIGN que nous avons récupéré en utilisant les details de la commande ainsi que la passphrase entrée dans le champ Signature SHA-IN dans l’onglet “Contrôle de données et origine”, dans la section “Contrôles pour DirectLink” dans la page d’Information Technique, vous recevrez le message d’erreur “unknown order/1/s/".

Si le champ "SHASIGN" dans votre requête est vide, mais qu’une passphrase a été entrée dans le champ Signature SHA-IN dans l’onglet  “Contrôle de données et origine”, dans la section “Contrôles pour DirectLink” dans la page d’Information Technique (indiquant ainsi que vous voulez utilise une signature SHA pour chaque transaction), vous recevrez le message d’erreur “unknown order/0/s/".

2.4 Parsing de la réponse

Nous retournerons une réponse XML à votre requête. Veuillez vous assurer que vos systèmes sont bien en mesure de faire du parsing en recevant la réponse XML de manière aussi tolérante que possible afin d’éviter tout problème dans le futur, par exemple éviter les noms d’attributs sensibles à la casse, ne pas convenir d’un ordre spécifique pour les attributs retournés dans les réponses, s’assurer que les nouveaux attributs dans la réponse ne causeront pas de problème, etc.

Ce site utilise les cookies pour être capable de vous donner la meilleure expérience utilisateur. Si vous ne souhaitez pas accepter ces cookies, nous vous permettons de modifier les paramètres des cookies. Cliquez sur «Accepter» pour permettre tous les cookies de ce site.

Paramètres des cookies

Introduction

Fonctionnels

Les cookies fonctionnels assurent le bon fonctionnement du site et ne peuvent pas être désactivés.

Optimisés

Les cookies d'optimisation nous permettent d'analyser l'utilisation du site afin de l'améliorer.
C'est le niveau par défaut.

Personnalisés

Les cookies de personnalisation, utilisés pour les médias sociaux et la personnalisation avancée, nous permettent d'afficher vos informations en lien avec votre société.


Exemple de fonctionnalité autorisée

  • Mémorisation du pays préféré
  • Mémorisation de la langue préférée

Exemple de fonctionnalité non autorisée

  • Enregistrement des données personnelles des utilisateurs
  • Suivi anonyme via Google Analytics
  • Suivi à des fins de remarketing

Exemple de fonctionnalité autorisée

  • Mémorisation du pays préféré
  • Mémorisation de la langue préférée
  • Suivi anonyme via Google Analytics

Exemple de fonctionnalité non autorisée

  • Enregistrement des données personnelles des utilisateurs
  • Suivi à des fins de remarketing

Exemple de fonctionnalité autorisée

  • Mémorisation du pays préféré
  • Mémorisation de la langue préférée
  • Suivi anonyme via Google Analytics
  • Affichage de contenus en fonction de vos intérêts
  • Affichage de publicités en fonction de vos intérêts
  • Suivi à des fins de remarketing

Exemple de fonctionnalité non autorisée

  • Enregistrement de données personnelles