Lors d’une création de transaction, et en fonction du mode choisi, Sogenactif 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 Sogenactif Paypage.

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

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.

Sogenactif 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é, Sogenactif 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 Sogenactif. 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 Sogenactif.

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 message suivant est affiché à votre client.

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 Sogenactif. Le point de départ de ce délai débute à l’arrivée du client sur la page de paiement Sogenactif.

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

La saisie du numéro de carte peut être divisée par bloc de 4 numéros. Dans le cas d’Amex et de BCMC, cette option est adaptée à la longueur du numéro de carte.

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 :

Les pages de paiement Sogenactif 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 Sogenactif. Pour plus d’informations, veuillez consulter le guide d’utilisation Sogenactif 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 avec l'acquéreur.

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 Sogenactif 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,Sogenactif 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, Sogenactif 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, Sogenactif 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, Sogenactif 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,Sogenactif 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, Sogenactif 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, Sogenactif 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, Sogenactif 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 :

• Bancontact
• Bancontact mobile
• Cetelem 3X 4X CB
• Cetelem Presto
• Chèque-Vacances Connect
• iDEAL
• Sofortüberweisung

Le paiement par fichier est un échange d’informations en temps différé (en mode fichier) entre vous et Sogenactif. 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é Sogenactif.

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 Sogenactif 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é Sogenactif ;
3. Sogenactif 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 à Sogenactif ;
5. Sogenactif 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é Sogenactif ;
6. Vous récupérez le fichier « réponse » via votre compte FTP sécurisé Sogenactif 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 Sogenactif, 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.

La conversion dynamique de devise (DCC – Dynamic Currency Conversion) est un service financier prévu pour les titulaires des cartes VISA et MasterCard qui permet au client de payer dans sa devise et au commerçant d’être payé dans la sienne.

Le DCC permet à la banque locale qui est l’acquéreur (celle qui prend en charge le paiement en votre nom) et à vous de profiter des frais de change ajoutés normalement à de telles transactions par VISA, MasterCard et les banques émettrices internationales. Vous recevez toujours le règlement dans votre devise de base.

Pour utiliser la conversion dynamique de devise (DCC), vous devez :

• souscrire un contrat d’acquisition avec l’option DCC ;
• souscrire à un service de taux de change ;
• demander l’option DCC lors de l’inscription au service Sogenactif.

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

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

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

Via Sogenactif 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 Sogenactif 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 Sogenactif Office Serveur hors contexte de paiement

Via les interfaces Sogenactif Office Serveur ou Sogenactif 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 Sogenactif Office Serveur, Sogenactif Office Batch et Sogenactif Gestion.

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 Sogenactif Gestion, soit les journaux, soit en utilisant la fonction GetTransactionData via Sogenactif Office Serveur (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 Sogenactif Office Serveur, Sogenactif Office Batch et Sogenactif Gestion.

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 Sogenactif Office Serveur 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 Sogenactif Office Serveur, Sogenactif Office Batch et Sogenactif Gestion.

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 Sogenactif Office Serveur, Sogenactif Office Batch et Sogenactif Gestion. 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 Sogenactif. 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 Sogenactif Office Serveur.

La réponse manuelle vous est envoyée lorsque le client est redirigé vers votre site une fois le paiement en ligne (connecteur Sogenactif Paypage ) ou la gestion de wallet (connecteur Sogenactif 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 Sogenactif Paypage et Sogenactif In-App) ou à la requête de gestion de wallet (connecteur Sogenactif 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é.

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.

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.

L’option CHALLENGE vous permet de mettre en attente les transactions dont le score est ORANGE. Ceci vous permet de vérifier le risque avant de poursuivre les autres étapes d’acceptation : validation, ré autorisation ou remise en banque.

Si vous ne disposez pas de l’option CHALLENGE la transaction est acceptée.

Vous avez X jours pour mesurer le risque de la fraude et valider ou refuser la transaction. X est la valeur maximale entre la validité de l’autorisation et le délai de capture (captureDay) que vous avez défini lors du paiement.

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 – Scoring » et souhaitent bénéficier d’un outil de lutte contre la fraude administrée par eux-mêmes sur le Portail Sogenactif.

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 Scoring.