Évaluation du risque avec Kount

L’intégration des endpoints (points de terminaison) de la nouvelle API de Moneris pour Kount demande l’utilisation du collecteur de données de Kount afin qu’il procure des données pour l’évaluation du risque qui sera effectuée avant que l’API ne fasse un appel à Moneris.

1. Pour commencer

L’intégration des endpoints (points de terminaison) de la nouvelle API de Moneris pour Kount demande l’utilisation du collecteur de données de Kount afin qu’il procure des données pour l’évaluation du risque qui sera effectuée avant que l’API ne fasse un appel à Moneris. Lorsque la collecte de données est terminée, votre solution pourrait choisir de faire un appel à la requête POST de création d’évaluation de Kount avant ou après la transaction financière.

2. Intégration à Kount

Valeurs

kountAccountID
760000

kountApiKey
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiI3NjAwMDAiLCJhdWQiOiJLb3VudC4xIiwiaWF0IjoxNTU4MDQwODQ5LCJzY3AiOnsia2EiOm51bGwsImtjIjpmYWxzZSwiYXBpIjp0cnVlLCJyaXMiOnRydWV9fQ.y3_2yzd11-Y_F6_xzVsXI-NO1a7P6ldMjDnKzl5yBko

websiteID
BASIC1

Identifiants (credentials) tests pour Kount Essentiel

Tous les comptes de Moneris avec un environnement bac à sable peuvent tester les solutions de Kount Essentiel et n’ont pas besoin de passer par un processus d’intégration particulier. Suivez ces consignes pour modifier vos appels à l’API /kount-inquiries pour les tests.

  1. Incluez les valeurs du volet ci-contre dans vos appels tests pour les champs de l’endpoint (du point de terminaison) /kount-inquiries :

  2. Utilisez les identifiants pour l’OAuth et l’information test qui vous a été fournie dans votre compte du portail pour développeurs de Moneris.

Valeurs

kountAccountID
Fournie par le gestionnaire de la réussite client de Kount

kountApiKey
Fournie par le gestionnaire de la réussite client de Kount

websiteID
Fournie par le gestionnaire de la réussite client de Kount

Identifiants (credentials) tests pour Kount Entreprise

Pour tester Kount Entreprise dans votre solution, vous aurez besoin d’identifiants tests propres à votre portefeuille de gestion du risque. Consultez votre gestionnaire de la réussite client de Kount.

  1. Incluez les valeurs du volet ci-contre dans vos appels tests pour les champs de l’endpoint (du point de terminaison) /kount-inquiries :

  2. Utilisez les identifiants pour l’OAuth et l’information test qui vous a été fournie dans votre compte du portail pour développeurs de Moneris.

Identifiants (credentials) de production pour Kount Essentiel

Pour les commerçants qui utilisent la solution Kount Essentiel de Moneris, veuillez envoyer un courriel à api@moneris.com pour obtenir vos identifiants de production kountAccountID, kountApiKey et websiteID.

Identifiants (credentials) de production pour Kount Entreprise

Pour les commerçants qui utilisent la solution Kount Entreprise de Moneris, veuillez consulter votre gestionnaire de la réussite client de Kount pour obtenir vos identifiants de production kountAccountID, kountApiKey et websiteID.

3. 3. Collecteur de données de Kount
(Kount Data Collector)

Le collecteur de données fournit des données concernant l’appareil qui amorce la transaction. Il fonctionne en arrière-plan, alors que la page Web charge dans le navigateur ou l’application mobile d’un client. Les données récoltées sont utilisées conjointement avec les données de l’évaluation du risque de Kount.

Processus du collecteur de données (Kount)

  • L’acheteur se rend sur la page du formulaire de commande qui contient le code du collecteur de données.

  • L’application mobile ou le navigateur de l’acheteur demande automatiquement à être redirigé à l’élément du collecteur de données.

  • Le navigateur de l’acheteur est redirigé vers les serveurs de Kount.

  • Kount collecte les attributs de l’appareil.

  • Kount dirige le navigateur de l’acheteur afin que celui-ci affiche une image statique hébergée par le commerçant.

Collecteur de données (trousses SDK dans une application)

Kount offre l’implémentation de son service de collecteur de données pour les appareils mobiles et les navigateurs Web. Kount possède des trousses SDK natives pour mobiles, autant pour iOS qu’Android, qui récoltent plus de données et augmentent la fiabilité de l’ID de l’appareil au cours de sa vie.

Trousse SDK pour iOS

Installation et configuration de la trousse SDK et exemples*
*Seulement disponible en anglais

IOS SDK on Github

Trousse SDK pour Android

Installation et configuration de la trousse SDK et exemples*
*Seulement disponible en anglais

Android SDK on Github

Collecteur de données : intégration Web

L’intégration Web de Kount demande le téléchargement de la trousse SDK de collecte de données de l’appareil de Kount afin qu’il soit utilisé de façon dynamique sur la page Web. Les exemples de JavaScript pour l’intégration ainsi que les étapes à suivre se trouvent ci-dessous.

Exigences du processus du collecteur de données

  1. Le port 443 doit être disponible pour envoyer et recevoir les données de Kount.

  2. Le code peut être inséré n’importe où sur la page Web avant l’envoi de la commande. Pour obtenir des résultats plus rapidement, vous devriez placer ce code dans le haut du code HTML de la page.

  3. L’utilisation d’un ID de session est requise. (Session ID)

    L’ID de session est l’identifiant unique utilisé pour l’événement de collecte et est propre à la requête de l’utilisateur. Vous utiliserez l’ID de session pour tous les appels ultérieurs au service d’évaluation.

    Exigences de l’ID de session

    • L’ID doit être unique à chaque requête. Ce dernier doit être unique pendant un minimum de 30 jours.

    • L’ID de session doit seulement contenir des caractères alphanumériques (des chiffres de 0 à 9, des lettres minuscules de a à z ou majuscules de A à Z), des tirets (–) ou des tirets bas (_).

    • L’ID de session devrait contenir 32 caractères. Un ID de session qui contient moins de 32 caractères sera accepté, mais nous recommandons fortement de respecter cette exigence.

Détails de l’implémentation

Nous vous conseillons de créer un ID de session qui sera envoyé à Kount en créant un ID de session qui répond aux critères décrits ci-dessous et en l’incluant dans l’appel de téléchargement de la trousse SDK de collecte de données de l’appareil (implémentation Web seulement). Dans cet exemple, l’ID de session utilisé est abcdefg12345abababab123456789012.
L’appel de téléchargement de la trousse SDK l'utilisant ressemble à ceci :

Configuration du client et du navigateur Web

1. Téléchargement de la trousse SDK de collecte de données de l’appareil de Kount

La trousse SDK de collecte de données de l’appareil de Kount est hébergée par Kount et doit être téléchargée de façon dynamique afin d’être utilisée sur une page Web.

Le code suivant peut être utilisé pour télécharger la trousse SDK :

URL du DATA_COLLECTOR:

Environnement bac à sable:
https://tst.kaptcha.com

Environnement de production:
https://ssl.kaptcha.com

2. Politique de sécurité du contenu

Si votre organisation a instauré une politique de sécurité du contenu sur votre site Web qui entre en conflit avec l’exécution de la collecte de données de l’appareil sur votre site, vous devrez l’ajouter à votre page.

3. Configuration du déclencheur

Le processus de collecte de la trousse SDK du collecteur de données de l’appareil est déclenché de façon asynchrone par la valeur « load » du champ « data-event ». Ceci permet au collecteur d’avoir le plus de temps possible pour accomplir sa tâche. La collecte est liée à l’événement de chargement de la page par l’ajout de la classe « kaxsdc » et du paramètre « data-event=‘load’ » à un élément HTML comme le corps du code HTML ou une balise « div ». Voici à quoi ça ressemble :

4. Configuration du client

Le code JavaScript du collecteur de Kount est associé à l’espace de nommage de l’objet JavaScript « ka ». Il est nécessaire d’ajouter la balise script « /collect/sdk » ci-dessus à votre page, ce qui importera la trousse SDK du collecteur de données de l’appareil.

Pour commencer à utiliser la trousse SDK du collecteur de données de l’appareil :

  • Créez un nouvel objet « ClientSDK »;

  • Configurez les méthodes de rappels (Callback)
    (facultatif).

La trousse SDK fournit un système de rappel programmable qui permet au client d’exécuter du code personnalisé à certaines étapes du processus de collecte de données. Cette méthode permet au commerçant d’ajouter une fonction de rappel qui sera appelée à une entrée précise du cycle de vie. Un commerçant peut transmettre un objet JavaScript contenant une ou plusieurs entrées du cycle de vie contenant un pointeur de fonction ou une fonction anonyme à exécuter.

Listes des entrées (en ordre de déclenchement) :

  • « collect-begin » : se déclenche lorsque la collecte commence

  • « collect-end » : se déclenche lorsque la collecte prend fin

Lorsqu’exécuté, un objet JavaScript est transmis à la fonction de rappel. Celui-ci contient les propriétés suivantes :

  • « MercSessId » : l’ID de session utilisé pour la collecte

  • « MercSessId » : l’ID de session utilisé pour la collecte

Événements autochargés (Auto Load)

Appelez la méthode « autoLoadEvents » sur le client afin d’y joindre le processus de collecte qui sera automatiquement déclenché par l’événement de chargement des éléments de la page qui contient le champ « className » avec la valeur « kaxsdc », qui a été configurée à l’étape 3.

REMARQUE

Il est recommandé d’insérer le code du collecteur de données au début du chargement de la page afin qu’il ait suffisamment de temps pour s’exécuter avant qu’un utilisateur ne finisse son interaction avec la page Web.

Exemple de code

Ce code est un exemple qui montre où chaque composante mentionnée ci-dessus s’affiche dans la page Web. Utilisez cet exemple pour vous aider à déterminer quel est le meilleur emplacement sur votre site Web pour l’intégrer à celui-ci.

4. Évaluation du risque de Kount

Faut-il effectuer une évaluation du risque avant ou après le paiement?

Une requête d’évaluation du risque peut être effectuée avant ou après la transaction de paiement d’un acheteur. Si elle est effectuée avant le paiement, la cote de risque sera moins complète puisque certains renseignements importants ne pourront pas être collectés.

  • Pour les commerçants qui comptent demander une évaluation du risque de Kount avant le paiement, Moneris recommande d’utiliser d’abord les transactions de validation de l’API de Moneris. Une transaction de validation permet une vérification rapide du NVC et du SVA avant de faire un appel à Kount, ce qui vous permet d’alimenter votre évaluation du risque de Kount avec les résultats de chaque outil.

  • Pour les commerçants qui comptent demander une évaluation du risque de Kount après le paiement, Moneris recommande d’automatiser votre solution en ce qui concerne la validation du résultat de la cote de risque et l’annulation des paiements réussis, comme suggéré par Kount, avec un champ « kountResult » contenant la variable « DECLINED ». Vous pouvez aussi implémenter des processus de révision manuels ou annuler les transactions dont le champ « kountResult » contient la variable « REVIEW ».

Durant l’expérience de paiement du client dans votre application ou sur votre site Web, le serveur du commerçant pourrait effectuer une requête POST de création de demande d’évaluation de Kount afin de générer l’évaluation du risque. Moneris se connectera au service d’évaluation du risque de Kount et fournira les données de l’appel API à Kount afin de générer l’évaluation du risque.

Consultez notre Référence API pour connaître tous les détails, mais assurez-vous d’inclure ce qui suit :

  • la valeur « sessionID », qui doit correspondre à la valeur que vous avez créée pour le processus du collecteur de données de cet acheteur un peu plus tôt. Elle lie les données récoltées par Kount directement à votre prochain appel à l’API.

À la réception de la réponse à votre requête POST de création de demande d’évaluation de Kount, votre solution doit effectuer une légère gestion des réponses, qui va au-delà du code d’état HTTP (Status code) renvoyée par votre API. Dans votre solution :

  • La valeur « kountResult » renverra la décision automatique suggérée par Kount vis-à-vis l’évaluation du risque. Si une transaction renvoie la valeur APPROVED, cela signifie qu’elle a reçu une cote de risque réussie pour le portefeuille du commerçant. Les valeurs DECLINED ou REVIEW indiquent que les risques sont trop élevés pour continuer le traitement de la transaction.

  • Le champ « fraudScore » renverra l’OmniScore de Kount provenant de l’évaluation du risque. Pour les commerçants utilisant Kount Entreprise, il pourrait servir à tester et rectifier le portefeuille de risque établi par votre gestionnaire de la réussite client de Kount.

5. Traitement du paiement

Traitement du paiement

Processus d’achat de base Processus en deux étapes : préautorisation et conclusion

Finalement, le commerçant pourra traiter la transaction financière par l’entremise d’une requête POST de création de mode de paiement. Utilisez notre Référence API pour connaître tous les détails et suivez l’un des deux processus suivants :

6. Validation des données de la commande
(pour Kount Entreprise seulement)

Voici une liste des éléments que nous vous recommandons de tester et de configurer:

1. Créez et vérifiez les UDF
2. Collecte de données sur l'appareil
3. Adresse e-mail du client
4. Numéro de commande du commerçant
5. Informations sur le panier
6. Adresse et téléphone
7. Informations de paiement
8. Tester les modifications de la liste VIP

Script de test Moneris Kount Entreprise

Il est recommandé d'utiliser des scripts de test pour valider que les données arrivent à Kount comme prévu et pour prouver les actions attendues dans votre système de gestion des commandes en fonction de la réponse ou de la réponse de Kount. - remplacer pour le premier segment.

Vous trouverez ci-dessous quelques exemples et actions que vous souhaiterez peut-être entreprendre pour valider votre soumission de données et les actions au sein de Kount et de vos systèmes en fonction des réponses de Kount. Tout cela est facultatif, mais fortement recommandé.

Alors que certains de ces exemples expliquent comment configurer des éléments dans le système, d'autres sont des recommandations de détails de commande à soumettre pour tester la fonctionnalité et la configuration.

Pour créer une FDU, procédez comme suit:

  1. Dans la console Web de l'agent (AWC), cliquez sur l'onglet Contrôle de la fraude, puis cliquez sur Champs définis par l'utilisateur.

  2. Sur la page Champs définis par l'utilisateur, en bas à droite, cliquez sur "add UDF".

  3. Dans la zone "Add UDF", entrez le nom de la UDF dans la zone de texte Étiquette. Une étiquette peut contenir au maximum 28 caractères et le premier caractère doit être une lettre..

  4. Saisissez une description dans le champ Description.

  5. Sélectionnez Nombre, Alphanumérique, Date ou Montant dans le menu déroulant Type. Remarque : les UDF destinées à être utilisées dans une liste VIP doivent être alphanumériques.

  6. Cliquez sur "Save UDF".

1. Créez et vérifiez les UDF

Pour les commerçants qui ont l'intention de transmettre des données supplémentaires dans Kount sous la forme d'un champ défini par l'utilisateur (UDF), vous devez créer des entrées « d'étiquette/label » appropriées dans la console Web de Kount Agent (AWC).

2. Collecte de données sur l'appareil

Le service d'enquête sur les risques (RIS) associe les données de l'appareil fournies par le processus de collecte de données aux données de commande client envoyées par le commerçant. Une fois les données de l'appareil et les données de commande combinées, RIS évalue et note chaque transaction.

Il convient de vérifier ci-dessous, sur la page des détails de la transaction, que le collecteur de données de l'appareil fonctionne correctement et qu'un identifiant de session unique est transmis à Kount lors de chaque demande de risque.

3. Adresse e-mail du client

Vérifiez que vous pouvez afficher l'adresse e-mail du client sur la page Détails de la transaction.

Remarque : Dans les cas où vous n'avez pas d'e-mail valide, vous serez noemail@kount.com et vous ne verrez aucune valeur affichée. Sinon, vous verrez l'e-mail comme indiqué ici

4. Numéro de commande (order number) du commerçant


Vérifiez que vous pouvez afficher le numéro de commande interne du commerçant sur la page Détails de la transaction (Transaction Details Page).


NOTE: the double hyphen “--“ between PROD_TYPE and PROD_ITEM is a formatting separator that Kount inserts and should not be placed in data sent or rule conditions.

5. Informations sur le panier

Les détails du panier sont requis dans Kount.  Vous trouverez ci-dessous une liste de contrôle des champs obligatoires du panier dont il convient de vérifier qu'ils s'affichent correctement sur la page Détails de la transaction de la console Web de votre agent.

  1. Product_Type (type de produit)

  2. Item_Type (type d'item)

  3. Description

  4. Price (prix)

  5. Units (unités)

  6. Total Amount (somme totale)

Cette liste à puces correspond à la capture d'écran.

  1. PROD_TYPE doit être une description de haut niveau de l’élément et peut être utilisée dans les règles.

  2. PROD_ITEM s'agit généralement du numéro SKU de l'article et peut être utilisé dans les règles.

  3. PROD_DESC est une description spécifique de l'élément, peut être longue et descriptive mais n'est pas disponible pour déclencher des règles.

  4. PROD_PRICE est le prix par unité.

  5. PROD_QUANT est la quantité.

Billing (Facturation)
Adresse postale, ville, état, code postal, pays, téléphone de facturation

Shipping (Expédition)
Adresse postale, ville, état, code postal, pays, téléphone de facturation

6. Adresse et téléphone

Vérifiez sur la page Transaction Details (Détails de la transaction) les champs d'adresse de facturation et d'expédition que vous pouvez envoyer à Kount.  Pour les calculs de distance et pour les services de vérification d'adresse (le cas échéant), le code du pays ISO à deux chiffres et le code postal respectif sont requis.

7. Informations de paiement

Les informations de paiement seront cruciales pour votre utilisation globale réussie de Kount.   Kount propose plusieurs méthodes de paiement et nous vous suggérons de soumettre des transactions tests avec toutes celles qui sont pertinentes pour votre entreprise, en vérifiant les éléments suivants sur la page TransactionDetails (Détails de la transaction) de la console Web de votre agent:

  1. Total de la commande dans la devise achetée (le code de la devise sera affiché)

  2. Total dans votre devise de base (le code de la devise sera affiché)

  3. Type de paiement (le type de paiement correct est affiché)

  4. Envoi des données brutes de la carte au SDK pour le hachage (le SDK Kount hachera le numéro brut de la carte pour la conformité PCI) – vérifiez que vous pouvez afficher le pays Bin Country)

  5. Bin et Bin Country (ceux-ci seront « inconnus » pour les cartes AMEX et Discovery)

  6. L'indicateur AUTH doit être mis au vert sur les transactions avant la certification

8. Tester les modifications de la liste VIP

Suivez ces actions pour prouver le flux de travail ou les actions attendues dans votre système de gestion des commandes (OMS) en fonction de la réponse ou de la réponse de Kount.

  1. Ajoutez l'adresse e-mail JohnDoeApprove@Acme.com à la VIP Approve list (liste d'approbation VIP) dans l'environnement de test.

  2. Ajoutez l'adresse e-mail JohnDoeDecline@Acme.com à la VIP Decline list (liste de refus VIP) dans l'environnement de test.

  3. Ajoutez l'adresse e-mail JohnDoeApprove@Acme.com à la liste VIP Review dans l'environnement de test.

  4. Passez une commande test en utilisant n'importe quel article via le front-end du site Web de test.

    • Lorsque vous remplissez les informations client, utilisez JohnDoeApprove@Acme.com comme adresse e-mail.

    • Remplissez les informations nécessaires sur la carte de crédit test.

  5. Confirmez qu'une fois la commande passée, le message d'expérience client approprié s'affiche.

  6. Vérifiez que le message apparaît comme approuvé, refusé ou en cours de révision, respectivement, dans la console Web de l'agent (AWC).

  7. Répétez avec deux autres e-mails pour forcer la réponse respective.

Scénarios de tests facultatifs supplémentaires

Renseignements additionnels

Définitions de l’API

Consultez les endpoints (points de terminaison), les formats des demandes et des réponses, ainsi que les modes d’authentification de ce scénario.

Définitions de l’API