Comment créer des ensembles de règles pour RDR avec Verifi

RDR se basera sur les règles que vous avez définies lors de votre inscription pour « accepter » automatiquement un pré-litige Visa en votre nom. Les règles sont constituées de conditions qui reflètent les attributs de la transaction contestée, tels que le montant de la transaction ou l'identifiant de l'achat. Dans le processus d'évaluation des règles, le résultat se traduira soit par une réponse « accepter », soit par une réponse « refuser ».

Ce guide vous explique tout ce que vous devez savoir pour établir correctement vos règles afin d'éviter les contestations de paiement par RDR.

Comprendre les règles RDR

Les règles sont composées de plusieurs éléments principaux :

Intitulé de la règle

Attributs de la règle

Attribut

Définition

Numéro de compte personnel BIN

BIN de l'émetteur à 6 chiffres

Date de la transaction

Date à laquelle la transaction a eu lieu

(Exemple de format : JJ/MM/AAAA)

Montant de la transaction

Montant total de la transaction

(Exemple de format : 10,00)

Code de devise de la transaction

Code de devise ISO de la transaction

(Exemple : USD)

Identifiant d'achat

Identifiant unique de la commande attribué à chaque transaction.

Transmis à l'émetteur par l'acquéreur afin d’identifier la commande du client en vue d'une résolution automatisée.

Catégorie de litige

Code défini par Visa pour catégoriser le litige

(Exemple : 10- Fraude, 11- Autorisation, 12- Erreurs de traitement, 13- Litiges avec les consommateurs. Veuillez vous référer au tableau ci-dessous pour consulter toutes les catégories de litiges)

Code de condition du litige

Sous-code de la catégorie de litige visant à mieux catégoriser le litige

  • (Exemple : 10.4 - Autre fraude - Environnement sans présentation de la carte, 13.3 - Marchandises/services non conformes à la description ou défectueux)

Opérateurs de la règle

Opérateur

Définition

Contains

L’attribut doit contenir la valeur spécifiée

EqualTo

L’attribut doit être égal à la valeur spécifiée

GreaterThan

L’attribut doit être supérieur à la valeur spécifiée

GreaterThanOrEquals

L’attribut doit être supérieur ou égal à la valeur spécifiée

IsBlank

L’attribut ne contient pas de valeur. Peut renvoyer Vrai ou Faux.

LessThan

L’attribut doit être inférieur à la valeur spécifiée

LessThanOrEquals

L’attribut doit être inférieur ou égal à la valeur spécifiée

NotEqualTo

L’attribut ne doit pas être égal à la valeur spécifiée

StartsWith

L’attribut doit commencer par la valeur spécifiée

IsIn

L’attribut doit contenir les valeurs possibles choisies.

  • Remarque :Pour la date de la transaction, les valeurs possibles sont 30, 60 ou 90 jours.

IsNotIn

L’attribut ne doit pas contenir les valeurs possibles choisies.

  • Remarque : Pour la date de la transaction, les valeurs possibles sont 30, 60 ou 90 jours.

Valeurs de la règle

Attribut

Format

Valeurs possibles

Opérateurs de possibilité

Numéro de compte personnel BIN

Numéro

Doit être le BIN de l’émetteur

à 6 chiffres.

Contains, EqualTo, IsBlank,

NotEqualTo, StartsWith

Date de la transaction

Date

Date au format JJ/MM/AAAA

EqualTo, NotEqualTo,

GreaterThan,

GreaterThanOrEquals, IsIn,

IsNotIn, LessThanOrEquals,

LessThan

Code de devise

de la transaction

Liste déroulante ou saisie libre

Alphanumérique

Codes de devise ISO 4217

Sélectionnez la devise de la

transaction dans la

liste déroulante. Vous pouvez sélectionner

plusieurs valeurs pour « IsIn »

et « IsNotIn ».

Contains, EqualTo, IsBlank, IsIn,

IsNotIn, NotEqualTo, StartsWith

Identifiant d'achat

Alphanumérique

Doit être l’identifiant unique de la commande attribué à chaque transaction.

Contains, EqualTo, IsBlank, IsIn, IsNotIn, NotEqualTo, StartsWith

Catégorie de litige

Liste déroulante ou saisie libre

Sélectionnez une des catégories ci-dessous :

10- Fraude

11- Autorisation

12- Erreurs de traitement

13- Litiges avec les consommateurs

Contains, EqualTo, NotEqualTo,

IsBlank, IsIn, IsNotIn

Code de condition du litige

Liste déroulante ou saisie libre

Sélectionnez le code

approprié dans le tableau ci-dessous

Contains, EqualTo, NotEqualTo

Éléments à prendre en compte lors de la création des règles

Voici quelques principes à garder à l'esprit lorsque vous établissez vos règles :

  1. Des règles doivent être définies pour chaque combinaison de BIN/CAID du marchand.
  2. Chaque BIN/CAID peut comporter jusqu'à 10 règles différentes. Une règle peut comporter jusqu'à 7 conditions.
  3. Tous les champs de la règle (attribut, opérateur, valeur) doivent être remplis. Ne laissez aucun champ vide.
  4. Certains attributs peuvent utiliser des opérateurs de comparaison approximatifs tels que « StartsWith » ou « Contains ». Ces attributs doivent contenir une valeur comportant au moins un caractère ou un chiffre.
  5. Il est vivement conseillé de ne pas utiliser la saisie libre (le cas échéant) avec des opérateurs de comparaison approximatifs tels que « Contains » et « IsIn ». Cela peut entraîner l'acceptation de plusieurs dossiers présentant des similitudes.
  6. Les règles sont évaluées dans l'ordre (la règle 1 est évaluée en premier, puis la règle 2, etc.) S'il y a cinq règles et que les conditions de la première règle sont remplies, les autres règles ne sont pas évaluées.
  7. Si les conditions d'une règle sont remplies, le pré-litige est « accepté », ce qui entraîne le remboursement du titulaire de la carte.
  8. Si une règle comporte plusieurs conditions, toutes les conditions de la règle doivent être remplies pour que la responsabilité soit « acceptée ».
  9. Si aucune des conditions des règles que vous avez créées n'est remplie, le pré-litige est « refusé » et donne lieu à une contestation de paiement.
  10. Pour tout dossier RDR « accepté », l’intitulé de la règle qui a permis la résolution du pré-litige est communiqué à l’acquéreur et à l'émetteur du titulaire de la carte afin de leur signaler la raison pour laquelle le litige a été résolu.

Bonnes pratiques pour la gestion des règles

  1. N'incluez pas de catégories de litiges et de codes de conditions contradictoires (par exemple, une catégorie de litige « 10 » ne peut pas avoir un code de condition du litige « 12.1 »).
  2. Une règle ne doit pas entrer en conflit avec une autre règle (par exemple, une règle ne peut pas être « La date de la transaction IsGreaterThan 01/01/2020 » si une autre est « La date de transaction IsLessThan 01/01/2020 »)
  3. Si une des conditions d’une règle concerne le montant de la transaction, une condition correspondante doit concerner le code de devise de la transaction.
  4. Les intitulés des règles doivent être courts, explicites et suffisamment clairs pour pouvoir être cités dans les communications de RDR. Nous vous recommandons de ne pas dépasser 30 caractères.

Catégorie de litige et codes de condition

10. Fraude

11. Autorisation

12. Erreurs de traitement

13. Litiges avec les consommateurs

10.1 - Fraude due au transfert de responsabilité d’une carte EMV contrefaite

10.2 - Fraude due au transfert de responsabilité d’une carte EMV non contrefaite

10.3 - Autre fraude - Environnement avec présentation de la carte

10.4 - Autre fraude - Environnement sans présentation de la carte

10.5 - Programme de surveillance Visa contre les fraudes

11.1 - Bulletin de récupération de carte

11.2 - Autorisation refusée

11.3 - Absence d'autorisation

12.1 - Règlement tardif

12.2 - Code de transaction non valide

12.3 - Devise non valide

12.4 - Numéro de compte non valide

12.5 - Montant non valide

12.6 - Doublon de traitement/transaction réglée avec un autre moyen de paiement

13.1 - Marchandises/services non reçus

13.2 - Paiement récurrent annulé

13.3 - Marchandises/services non conformes à la description ou défectueux

13.4 - Marchandises de contrefaçon

13.5 - Représentation non factuelle

13.6 - Crédit non traité

13.7 - Marchandises/services annulés

13.8 - Transaction de crédit initiale non approuvée

13.9 - Espèces ou montant de la transaction de recharge non reçu