Le moteur de règles d'acceptation est une brique applicative puissante et modulaire qui permet d'adapter le comportement lié au traitement à réaliser sur chaque transaction comme :
- accepter
- refuser
- accepter en 3DS
- accepter avec CVV
- demande d’OTP
- alerter
- …
Ce service permet ainsi de définir des actions à réaliser sur chaque transaction depuis une large liste d’attributs disponibles : score de fraude, localisation du porteur, montant des ventes cumulées sur 7 ou 30 jours, client VIP whitelist, paramètre spécifique adressé par le marchand...
Le système de traitement des transactions se compose de plusieurs étapes consécutives dont les règles s'enchaînent toujours dans un ordre prédéfini (voir schéma ci-dessous).
Le système de traitement d'une transaction se découpe en trois étapes :
1Whitelist :
Le but de la "whitelist" est de rendre sélective l’application d’une règle.
La règle définie devient inopérante pour des clients identifiés, VIP ou reconnus de confiance qui sont intégrés à une "whitelist".
Le service passe ainsi à l’étape suivante.
Les "whitelists" portent sur les données spécifiques d'un client, comme le numéro de sa Carte Bancaire ou son adresse IP.
Cette fonctionnalité permet d’être moins restrictif sur des populations d’utilisateurs.
2Blacklist :
L’étape de la "blacklist" permet de refuser les paiements.
Tout comme pour les "whitelists", les "blacklists" portent sur les données propres au porteur de carte (Carte, IP, Tel, email).
3Acceptance :
Cette étape permet de construire les règles spécifiques définissant les conditions d’acceptation d’un paiement.
Les phases de traitement des transactions sont toujours exécutées dans cet ordre.
- Dans le cas où les données d'entrée remplissent toutes les conditions des "whitelist" définies, la phase de "blacklist" ne sera pas exécutée et la transaction passera directement à la phase "Acceptance".
- Dans le cas où une opération rentre dans la phase de "blacklist", si les données d'entrée remplissent une des conditions des "blacklist" définies, le paiement sera refusé et la phase "Acceptance" ne sera pas exécutée.
- Chaque phase est exécutée de façon descendante vis à vis de la hiérarchie des acteurs du système de paiement.
L'organigramme ci-contre représente le fonctionnement hiérarchique du système de paiement.
Le système de traitement des transactions s'inscrit dans cette logique de hiérarchisation des acteurs.
En effet, chaque "Acteur" peut définir des règles pour des entités inférieures sur lesquels il possède les droits. En aucun cas une entité inférieure (marchand ou agent) ne peut définir, modifier ou consulter des règles portant sur une entité supérieure ou équivalente.
Les règles suivent donc la même hiérarchie que les acteurs dont les règles exécutées dans l’ordre ascendant.
NB : les droits sur les règles ne s’appliquent que sur des niveaux de N à N-1.