Lors d’une création de transaction, et en fonction du mode choisi, Mercanet accepte ou rejette la création et génère des identifiants complémentaires.

Différents cas sont possibles :

Pour les opérations de caisse, le mode d’identification d’une transaction n’est pas limité au mode choisi lors de la création.

Les tableaux ci-dessous reprennent les différentes possibilités.

Les champs s10TransactionId, s10TransactionIdDate et transactionReference sont présents dans les journaux de transactions, d’opérations, de rapprochements et d’impayés, quel que soit le mode d’identification de transaction.

Pour l'opération de duplication, la transaction d’origine est identifiable via les champs s10FromTransactionId, s10FromTransactionIdDate et fromTransactionReference du journal des transactions.

Pour plus de détails veuillez consulter les guides de personnalisation de Paypage.

La page de sélection des moyens de paiement Mercanet n’est pas affichée automatiquement. Elle peut être gérée soit sur votre site marchand soit par Mercanet. Une option permet d’afficher systématiquement cette page par Mercanet.

Néanmoins, dans le cas où les moyens de paiement ne sont pas du même type (carte et Paypal par exemple), la page de sélection s’affiche systématiquement. Quand plusieurs moyens de paiement sont configurés dans votre contrat, vous pouvez filtrer ceux qui s’afficheront dans la page de sélection des moyens de paiement grâce au champ paymentMeanBrandList :

• un seul moyen de paiement : la page de sélection des moyens de paiement ne s’affiche pas ;
• une liste de moyens de paiement : l’affichage des moyens de paiement se fait dans l’ordre d’alimentation du champ ;
• champ non renseigné : tous les moyens de paiement configurés s’affichent.

Mercanet affiche les moyens de paiement qui correspondent à la fois

• à la liste des moyens de paiement prévus dans votre configuration

et

• aux données de la transaction (contrôle de la devise de la transaction par exemple).

Si aucun moyen de paiement compatible n’est trouvé, Mercanet refuse la transaction.

Exemple d’affichage de la page de sélection du moyen de paiement :

La page de confirmation du paiement, appelée « ticket de paiement », est affichée par défaut par Mercanet. Néanmoins, vous pouvez choisir de l’afficher vous-même sur votre site en utilisant les éléments fournis dans le message de réponse envoyé à l’URL de réponse (normalReturnUrl). Vous pouvez également décider dynamiquement, en fonction du contexte de la transaction, de ne pas afficher le ticket produit par Mercanet.

Vous pouvez décider du nombre de tentatives maximum de saisie du PAN

• quand un client accède à la page de saisie des informations de paiement ;
• ou qu’un utilisateur saisit via Mercanet Back Office.

Au-delà de cette limite, la transaction est refusée et le message suivant s’affiche :

Habituellement, une nouvelle tentative de paiement est proposée au client uniquement en cas de saisie de PAN invalide. Cette option supplémentaire permet d’étendre les nouvelles tentatives de paiements sur d’autres types de refus :

• refus de l’acquéreur, non typé fraude ;
• authentification 3DS échouée ;
• refus de l’outil de lutte contre la fraude, non typé fraude.

Le nombre de tentatives de paiement est paramétrable dans votre configuration commerçant (voir paragraphe précédent « Nombre de tentatives de paiement »).

Le message suivant est affiché à votre client.

Vous pouvez choisir de faire envoyer une notification automatique à votre site en cas d’erreur technique. Ce type d’erreur intervient de manière exceptionnelle.

Un délai de 15 minutes d’inactivité est accordé au client pour lui permettre de réaliser son paiement. Au-delà de ce temps imparti, la session utilisateur expire, et il n’est plus possible pour le client de finaliser son achat. Ce délai est fixé à 15 minutes, conformément à la réglementation PCI DSS (condition 8.1.7).

En complément de cette limitation réglementaire, vous avez la possibilité de proposer un délai de présence maximum sur les pages de paiement Mercanet. Le point de départ de ce délai débute à l’arrivée du client sur la page de paiement Mercanet.

Le nom de la boutique configuré dans Mercanet peut être affiché dans le bandeau de la page de paiement.

Afin de sécuriser la validité de la saisie, une option permet l'affichage d'un champ obligatoire en dessous de la zone de saisie des informations carte, demandant au titulaire de la carte de saisir son nom.

Cette option est disponible uniquement pour le paiement par carte.

Cette donnée est envoyée à certains acquéreurs dans la demande d’autorisation (principalement les acquéreurs anglais). Cependant, cette saisie peut être utilisée pour dissuader d’éventuels fraudeurs.

Cette page s’affiche en cas d’une erreur à l’initialisation de paiement uniquement via le connecteur POST (requête mal formatée par exemple).

Le bouton de redirection permet de rediriger l’internaute vers le site du commerçant (avec la réponse manuelle). L’affichage du bouton de redirection est configurable :

En parallèle, une réponse automatique peut être envoyée. L’envoi de cette réponse automatique est configurable :

Dans la page de saisie des informations du moyen de paiement, les données sensibles (numéro de carte et CVV) peuvent être masquées.

Si cette fonctionnalité est activée, alors le masquage de la saisie de données sensibles sera également effective lors de la création d'une transaction avec une carte de paiement dans l'interface Mercanet Back Office.

Les pages de paiement Mercanet peuvent être intégrées à une page de la boutique. Cela n’a aucun impact sur vos pages et vous pouvez utiliser cette fonction sans configuration Mercanet. Pour plus d’informations, veuillez consulter le guide d’utilisation Paypage iFrame.

Pour utiliser le canal Internet, vous devez souscrire un contrat VADS (vente à distance sécurisée) avec l’acquéreur.

Dans le cas des canaux MOTO, MAIL_ORDER ou TELEPHONE_ORDER, la transaction est traitée en acceptation vente à distance. Vous devez souscrire un contrat VAD (vente à distance) acceptant le canal MOTO avec l’acquéreur.

Le canal SVI (Serveur Vocal Intéractif ou encore Interactive Voice Response en anglais) est assimilé au canal MOTO. Vous devez donc souscrire un contrat VAD (vente à distance) acceptant le MOTO auprès de BNP Paribas.

L’utilisation du canal application mobile ne nécessite pas de configuration acquéreur. Pour en savoir plus sur ce connecteur, veuillez consulter le document In-App JSON.

Dans le cas du paiement en fin de journée, toutes les transactions acceptées durant la journée sont envoyées en remise en paiement le soir. Ce mode s’applique aux moyens de paiement fonctionnant dans le mode de « message double » souvent appelé « dual message » (un message pour l’autorisation et un message pour la remise).

Si cette modalité n’est pas supportée par le moyen de paiement,Mercanet surcharge le paramètre captureMode avec la valeur par défaut du moyen de paiement concerné (pour plus de renseignements, veuillez consulter les guides d’intégration des moyens de paiement).

Dans le cas du paiement différé, la remise en paiement de la transaction est effectuée N jours après l’acceptation en ligne.

La durée de validité des autorisations du moyen de paiement est fixée dans le contrat conclu entre vous et l’acquéreur (par défaut 6 jours pour CB, VISA et Mastercard).

En fonction de la durée de validité de l’autorisation, le nombre de jours de différé de remise communiqué dans la requête de paiement peut avoir une incidence sur le cycle de vie de la transaction :

• 1er cas : Le différé de paiement est inférieur ou égal à la durée de validité de l’autorisation. L’autorisation donnée par l’acquéreur est toujours valable pour le montant total de la transaction initiale. Si la transaction n’est pas annulée, elle est payée à la date de la transaction +N jours.
• Cas particulier 3-D Secure : pour bénéficier du transfert de responsabilité lors d'une transaction 3-D Secure, le différé de paiement ne peut pas être supérieur à la durée maximale de validité de l’autorisation donné par l'acquéreur. Si nécessaire, Mercanet surcharge ce différé de paiement si la valeur que vous renseignez est supérieure.
• 2ème cas : Le différé de paiement est supérieur à la durée de validité de l’autorisation. L’autorisation donnée lors de l’achat en ligne par l’acquéreur n’est plus valable lors du paiement. En fonction de l’acquéreur, Mercanet choisit entre l’un des scénarios suivants :
  • Acquéreur conforme avec la fonctionnalité « Demande de renseignement » : Une demande de renseignement est envoyée à l’acquéreur dans le but de vérifier le numéro de carte de la transaction avant de réaliser une autorisation. Si la réponse est positive, Mercanet envoie la demande d’autorisation avec le montant réel de la transaction à J+N. En cas d’accord, la transaction est envoyée en remise.
  • Acquéreur non conforme avec la fonctionnalité « Demande de renseignement » : La procédure est identique mais la demande de renseignement faite en ligne est remplacée par une prise d'empreinte (demande d’autorisation d'un petit montant).
    Par conséquent,Mercanet fait deux demandes d’autorisation :

    • La première demande d’autorisation d'un petit montant, appelée l’empreinte, pour vérifier la carte lors de l’acceptation en ligne.
    • La deuxième demande d’autorisation pour le montant réel avant la remise en paiement.

Si le moyen de paiement est incompatible avec le différé demandé par vous, Mercanet surcharge le champ captureDay.

Dans le cas du paiement à l’expédition, la transaction est envoyée en remise en paiement suite à votre validation. Vous indiquez dans le champ captureDay la durée de validité de votre transaction. Si vous ne validez pas une transaction donnée avant que ce délai ne prenne fin, cette transaction expire. Si vous oubliez de valider dans les délais, vous pouvez représenter la transaction grâce à l’opération de duplication. Vous pouvez valider tout ou partie du montant de la transaction mais il est impossible de valider un montant supérieur au montant initial de la transaction.

Si le mode VALIDATION n’est pas supporté par le moyen de paiement, Mercanet le surcharge avec la modalité de paiement par défaut.

Dans le cas du paiement immédiat, la transaction est remisée lors de l’autorisation en ligne. Cette modalité de paiement est plus rarement utilisée, et uniquement pour les moyens de paiement supportant le mode « message unique » appelé aussi « single message » (un seul message pour l’autorisation et le paiement).

Si cette modalité n’est pas supportée par le moyen de paiement, Mercanet surcharge le paramètre captureMode avec la valeur par défaut correspondant au moyen de de paiement concerné (pour plus de renseignements, consultez les guides d’intégration des moyens de paiement).

Les moyens de paiement supportant ce mode sont les suivants :

• Cetelem 3X 4X CB
• Chèque-Vacances Connect

Le paiement par fichier est un échange d’informations en temps différé (en mode fichier) entre vous et Mercanet. Il vous permet de constituer des fichiers de transactions et/ou d'opérations puis de les déposer sur un compte FTP sécurisé Mercanet.

Il se distingue donc d'un nombre N d'informations communiquées en temps réel (mode transactionnel).

Mode fichier :

1. Vous disposez d’un nombre N de transactions de paiement et/ou d'opérations indépendantes (N1, N2, N3, N4, etc) ;
2. En vous basant sur les spécifications de Office Batch, vous constituez un fichier « requête » rassemblant ces transactions et/ou opérations, que vous déposez sur votre compte FTP sécurisé Mercanet ;
3. Mercanet effectue des contrôles de droits ainsi que de cohérence du fichier (format, taille), puis procède au traitement des informations contenues dans ce fichier et envoie les demandes d’autorisation vers les acquéreurs ;
4. Les acquéreurs traitent les demandes d’autorisation reçues et envoient les réponses à Mercanet ;
5. Mercanet construit le fichier « réponse » contenant les réponses aux paiements et/ou opérations et le dépose sur votre compte FTP sécurisé Mercanet ;
6. Vous récupérez le fichier « réponse » via votre compte FTP sécurisé Mercanet puis intégrez ce fichier dans votre propre système d’information.

Le paiement par fichier s’avère particulièrement utile si vous devez traiter un très grand nombre de flux puisqu’il vous évite d’avoir à apporter une réponse en temps réel à vos clients.

L’autorisation de l’acquéreur demeure valide pour une certaine durée (par défaut 6 jours pour CB, VISA et Mastercard) :

• durant ce délai, la transaction est envoyée en remise avec l’autorisation faite en ligne ;
• au-delà de ce délai, une nouvelle demande d’autorisation est envoyée à l’acquéreur avant la remise en paiement.

La durée de validité peut dépendre du contrat d’acquisition conclu entre vous et l’acquéreur, c’est pourquoi une option permet de fixer la durée de l’autorisation associée à votre contrat d’acquisition. Cette fonctionnalité n’est disponible que pour certains moyens de paiement, pour plus d’information, veuillez consulter les guides d’implémentation.

Dans le cas des transactions multidevises, l’acceptation porte sur la devise du client mais le paiement est réglé dans votre devise.

Vous devez souscrire cette option auprès de l’acquéreur.

Les étapes de l’acceptation des transactions multidevises sont les suivantes :

1. vous devez gérer le prix de vos ventes en ligne en plusieurs devises ;
2. lorsque vous soumettez la transaction au serveur Mercanet, vous renseignez la devise que vous désirez dans le champ currencyCode ;
3. la transaction est envoyée pour autorisation et pour la remise du paiement avec le même code de devise ;
4. lors de l’acquisition du paiement, l’acquéreur convertit la transaction dans votre devise de règlement.

Dans le cas du règlement en devise, l’acceptation et le règlement sont effectués dans la même devise.

Vous indiquez le code de la devise utilisée par le client dans la requête de paiement. Vous devez disposer d’un contrat d’acquisition et d’un compte bancaire dans les devises concernées.

Le paiement récurrent via Wallet est la solution Mercanet Abonnement.

Pour avoir une description fonctionnelle et les modalités d’implémentation du paiement par abonnement, veuillez consulter le document Paiement par abonnement.

Voici en synthèse les principaux cas d’utilisation.

Enregistrement du moyen de paiement dans le wallet lors d’un paiement Paypage

Via Paypage, vous pouvez demander l’enregistrement automatique du moyen de paiement dans le wallet en cas de paiement accepté.

Enregistrement du moyen de paiement dans le wallet via Walletpage hors contexte de paiement

Via l’interface Walletpage, vous pouvez demander à votre client de créer un wallet en y ajoutant un moyen de paiement.

Enregistrement d’un mandat dans le wallet via la méthode addDirectDebit de Office (M2M) hors contexte de paiement

Via les interfaces Office (M2M) ou Office Batch, vous pouvez créer un wallet pour votre client avec son numéro de mandat.

Pour les Nème paiements, vous utilisez la méthode walletOrder en renseignant l’identifiant du wallet dans le champ merchantwalletID

Vous pouvez annuler les transactions, non remisées, partiellement ou totalement en utilisant la fonction Annuler disponible dans les interfaces de Office (M2M), Office Batch et Mercanet Back Office.

Pour les moyens de paiement CB, Visa et Mastercard, l’opération d'annulation n’est plus possible sur une transaction dès l’exécution de son traitement de remise en banque.

Exemple : si une transaction (CB, Visa ou Mastercard) est effectuée à J, avec un captureDay paramétré à 2 et un captureMode AUTHOR_CAPTURE, il ne sepra plus possible de l'annuler à J+2 à partir de 22h00 CET.

Pour la majorité des autres moyens de paiement, les opérations d'annulation sont indisponibles tous les jours durant le traitement de la remise (voir Annexe 3 pour le détail des horaires), même sur les transactions non inclues dans la remise. La durée de traitement peut varier selon le nombre de transactions à remiser.

Il est possible de connaître la date de remise en paiement d'une transaction soit via Mercanet Back Office, soit les journaux, soit en utilisant la fonction GetTransactionData via Office (M2M) (dans le champ captureLimitDate).

Dans le cas d’une annulation totale, l’état de la transaction passe à « annulée » (transactionStatus CANCELLED), mais pour une annulation partielle, l’état reste inchangé.

Les contrôles suivants sont effectués :

• vous disposez du droit d’annulation. Dans le cas contraire un responsCode 40 est retourné ;
• la transaction existe dans notre base de données. Dans le cas contraire un responseCode 25 est retourné ;
• la transaction est au statut "TO_CAPTURE" ou "TO_VALIDATE" ou "TO_AUTHORIZE" ou "TO_CHALLENGE". Dans le cas contraire un responseCode 24 est retourné. Vous pouvez consulter les heures de remise par acquéreur / privatif en Annexe 3 ;
• le montant à annuler est égal ou inférieur au montant de la transaction. Dans le cas contraire un responseCode 51 est retourné ;
• aucune opération de caisse n'est déjà en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné.

Les transactions créées dans le mode validation (captureMode = VALIDATION), doivent être validées partiellement ou totalement pour déclencher le paiement en utilisant la fonction Valider disponible dans les interfaces de Office (M2M), Office Batch et Mercanet Back Office.

La transaction passe alors à l’état « à valider » (transactionStatus = TO_VALIDATE) ou à l’état « en attente d’une validation avec demande d’autorisation » (transactionStatus = TO_REPLAY), puis à l'état « à remiser » (transactionStatus = TO_CAPTURE) ou directement à l’état « remisée » (transactionStatus = CAPTURED) en fonction des règles du moyen de paiement.

Vous ne pouvez valider une transaction qu’une seule fois. Dans le cas d’un paiement partiel, le complément peut être réalisé grâce à l’opération de duplication.

Les contrôles suivants sont effectués :

• vous disposez du droit de validation. Dans le cas contraire un responseCode 40 est retourné ;
• la transaction existe dans notre base de données. Dans le cas contraire un responseCode 25 est retourné ;
• la transaction est au statut "TO_VALIDATE". Dans le cas contraire un responseCode 24 est retourné ;
• le montant à valider est inférieur ou égale au montant de la transaction. Dans le cas contraire un responseCode 51 est retourné ;
• la demande d'autorisation est acceptée par l’acquéreur dans le cas d'une validation avec demande d’autorisation (spécifique à quelques moyens de paiement). Dans le cas contraire un responseCode autre que 00 est retourné ;

• aucune opération de caisse n'est déjà en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné.

Cas des validations immédiates après le paiement

Votre métier de vente sur Internet vous a peut-être contraint à implémenter vos paiements en mode validation (champ captureMode = VALIDATION), et à envoyer une requête de validation via Office (M2M) immédiatement après le paiement, soit au retour de votre client sur votre site marchand, soit à réception de la réponse automatique. Ce mode de fonctionnement est valable, mais vous devez prendre quelques précautions de mise en œuvre et échanger avec votre chargé de compte pour qu'il(elle) valide votre choix.

Afin d'optimiser la réussite de vos ventes sur Internet, nous utilisons un système d'écriture en base de données de type asynchrone. Grâce à ce système d'écriture asynchrone, nous restons en capacité d'accepter vos transactions de paiement en temps réel, même si notre système base de données venait à subir quelques perturbations ou à ralentir.

Toutefois, lors d'une maintenance ou en cas d'engorgement ponctuel de notre système de base de données, les transactions s'enregistrent avec un temps de décalage par rapport au traitement temps réel du paiement. Il est par conséquent nécessaire de suivre les conseils ci-dessous pour votre implémentation de validations automatisées .

Dans le cas d’un paiement déjà remisé, vous pouvez rembourser la transaction partiellement ou totalement en utilisant la fonction Rembourser disponible dans les interfaces de Office (M2M), Office Batch et Mercanet Back Office.

Exemple : si un transaction (CB, Visa ou Mastercard) est effectuée à J, avec un captureDay paramétré à 2, il sera possible de la rembourser en totalité ou partiellement à J+2 après la fin du traitement de la remise.

Dans le cas d’un remboursement total, la transaction passe à l’état « à rembourser » (transactionStatus = TO_CREDIT) ou à l’état « remboursée » (transactionStatus = CREDITED) en fonction des règles du moyen de paiement.

En cas de remboursement partiel, l’état de la transaction redevient « envoyée en banque » (transactionStatus = CAPTURED) après le traitement de la remise.

Les contrôles suivants sont effectués :

• vous disposez du droit de remboursement. Dans le cas contraire un responseCode 40 est retourné ;
• la transaction existe dans notre bas de données. Dans le cas contraire un responseCode 25 est retourné ;
• la transaction est au statut CAPTURED ou TO_CREDIT. Dans le cas contraire un responseCode 24 est retourné. Vous pouvez consulter les heures de remise par acquéreur / privatif en Annexe 3 ;
• le montant à rembourser doit être inférieur ou égale au montant de la transaction. Dans le cas contraire un responseCode 51 est retourné ;
• la transaction à rembourser n'est pas en impayé. Dans le cas contraire, un responseCode 57est retourné ;
• aucune opération de caisse n'est déjà en cours sur la transaction. Dans le cas contraire, un responseCode 24 est retourné.

Vous pouvez créer une transaction à partir d’une transaction existante en utilisant la fonction « Duplication » disponible dans les interfaces Office (M2M), Office Batch et Mercanet Back Office. Cette fonction permet par exemple de recréer une transaction à partir d’une transaction qui a expiré par erreur, mais également de faire du paiement en plusieurs fois.

Les coordonnées du moyen de paiement sont récupérées de la transaction initiale par Mercanet. Toutefois, vous pouvez modifier les données métier (numéro de commande, modalité de remise en paiement, …).

Les transactions dupliquées sont traitées comme une nouvelle transaction en mode récurrent (champ paymentPattern fixé à RECURRING_N).

Les contrôles suivants sont effectués :

• vous disposez du droit de duplication. Dans le cas contraire un responseCode 40 est retourné;
• la transaction existe dans notre base de données. Dans le cas contraire un responseCode 25 est retourné;
• le moyen de paiement utilisé est compatible et permet la duplication. Dans le cas contraire, un responseCode 24 est retourné ;
• la date d’expiration du moyen de paiement est toujours valide. Dans le cas contraire, un responseCode 14 est retourné ;
• la demande d’autorisation est acceptée pas l’acquéreur et un responseCode 00 a été obtenu.

La fonctionnalité de diagnostic vous permet de connaître l’état détaillé d’une transaction indiquée dans votre requête via la fonction getTransactionData des interfaces Office (M2M).

La réponse manuelle vous est envoyée lorsque le client est redirigé vers votre site une fois le paiement en ligne (connecteur Paypage ) ou la gestion de wallet (connecteur Walletpage) effectué. Néanmoins, vous n’avez pas de garantie de récupérer la réponse manuelle car, le client peut décider de fermer son navigateur ou ne pas cliquer sur le bouton de retour à la boutique une fois son paiement réalisé ou sa gestion de wallet terminée.

Les champs retournés dans la réponse sont variables en fonction du résultat de la transaction (refusée ou réussie).

Pour assurer la récupération de la réponse à la requête de paiement (connecteurs Paypage et In-App) ou à la requête de gestion de wallet (connecteur Walletpage), vous pouvez demander l’envoi de la réponse dite automatique. La réponse est envoyée indépendamment du retour boutique du client. Les champs de la réponse sont variables en fonction du résultat de la transaction (refusée ou réussie).

L’adresse URL de la réponse automatique peut être fournie dans la requête, si elle n’est pas fournie, c’est celle de la configuration marchande qui est utilisée. Si elle n’est pas fournie et qu’aucune configuration n’a été faite, la réponse automatique n’est pas envoyée.

Le résultat de l’envoi de la réponse automatique vers le commerçant est renseigné dans le champ automaticResponseStatus d’une transaction de paiement. Les valeurs de ce champ (SENT, FAILED, TIMED_OUT) sont conditionnées par le code HTTP renvoyé.

Dans le cas où l'envoi de la réponse automatique est en échec (statut FAILED ou TIMED_OUT), un renvoi est réalisé au bout de 15 minutes. En tout 5 tentatives d'envoi de la réponse automatique sont effectuées en cas d'échec.

Cette notification est reçue par le client à la fin du processus de la transaction. Vous pouvez en recevoir une copie par e-mail sur une adresse configurée lors de l’activation de cette option. Le contenu de la notification est variable en fonction du résultat de la transaction (refusée ou réussie).

La notification au client peut être envoyée par e-mail ou SMS, si les deux champs sont renseignés, la notification par e-mail est choisie.

Le contrôle Oppotota avant remise (gestion des cartes en opposition), permet de vérifier que la carte utilisée n’a pas été mise en opposition entre la demande d’autorisation et la validation de la transaction ou sa remise en paiement.

Ce contrôle ne s’applique qu’aux transactions CB, VISA, MASTERCARD et n’est pertinent que si vos transactions sont traitées par une banque française du réseau CB.

Le fichier des cartes en opposition est alimenté en se basant sur la liste des cartes en opposition du réseau CB. La mise à jour du fichier est effectuée plusieurs fois par jour.

La fonctionnalité de diagnostic vous permet de récupérer des informations relatives au contrôle anti-fraude d'une transaction indiquée dans votre requête via la fonction getFraudData.

Le moteur de lutte contre la fraude s’adresse à tous les commerçants qui ont souscrit à l’offre « Gestion de la lutte contre la fraude – Business Score » et souhaitent bénéficier d’un outil de lutte contre la fraude administrée par eux-mêmes sur le Merchant Extranet.

Le moteur de lutte contre la fraude s’appuie sur des profils antifraudes afin d’évaluer les transactions. Ceux-ci sont composés de règles que vous pouvez configurer.

Pour avoir une description fonctionnelle et les modalités d’implémentation du contrôle des fraudes en ligne, veuillez consulter les documents Gestion de la lutte contre la fraude Go-No-Go et Gestion de la lutte contre la fraude Business Score.