Nouvelles fonctionnalités Monext Online #4.69
Environnement | Environnement | Version publiée |
Homologation | 12/01/2022 | 4.69 |
Production | 02/02/2022 | 4.69 |
De nouveaux écrans arrivent à chaque release. Avec cette version vous pouvez bénéficier de la nouvelle gestion des offres commerciales, règles de déliassage, et le module fraude en version bêta. Toujours plus fluides et plus conviviaux, ces écrans vous offrent une meilleure navigation.Nouveau Centre d'Administration
Payment facilitator
Vous pouvez désormais utiliser la fonction Payment facilitator pour les moyens de paiement Google Pay, Apple Pay, Samsung Pay et Paylib, simplement en utilisant l’object submerchant en entrée des web services de l'API Payline (version 18) permettant d'initier un paiement sur le contrat de ses commerçants affiliées. Veuillez consulter la documentation pour la gestion des contrats.
Fraude - Ajouter un élément "Pays inconnu"
Il arrive parfois que pour une carte bancaire ou une adresse IP nous n’ayons pas le pays correspondant. C’est par exemple le cas pour certaines cartes bancaires américaines, et notre outil de lutte contre la fraude ne permettait pas de déclencher une action fraude sur ces éléments. Nous avons donc ajouté l'élément « pays inconnu » à la liste des pays disponibles dans les contrôles des pays de carte, pays de l'acheteur et d’adresses IP.
Point de vigilance : dorénavant la valeur vide sera prise compte comme pays inconnu. Tous les critères de type pays d'une règle ou d'une liste seront appliqués et les transactions seront soumises à ces conditions.
Exemple : la règle pays de l'acheteur est configurée avec un refus de transaction pour pays inconnu, alors toutes les transactions avec le champ pays ayant la valeur vide/nulle (non fournie) ou de pays inconnu, seront refusées.
Softdecline avec Barclays
Vous pouvez désormais prendre en compte les refus Softdecline retournés par l'acquéreur Barclays. Cette fonction vous permet de déclencher le retry 3DS sur ces transactions en configurant votre contrat.
Monext vise à travers cette évolution à augmenter le taux de conversion. Lorsque Monext ne reçoit pas les informations sur le challenge lors de ses échanges avec la banque émettrice (ACS), le process de paiement se poursuit. Si le commerçant utilise les Pages Web de Paiement Monext ou le widget, il n'a rien à faire, cette reprise sur erreur est engagée par Monext de façon autonome et automatique. Si le commerçant utilise l'API DirectPayment, il peut, lorsqu'il ne reçoit pas le message CRes dans les douze minutes suivant l'envoi du CReq, poursuivre le traitement en fournissant uniquement le paramètre MD (sans fournir le contenu du CRes). Ce mode opératoire s'applique aussi bien lors de l'appel au web service verifyAuthentication qu'au doAuthorization.Traitement en l'absence de réception d'information sur le challenge 3DSv2
Précision sur les messages de retour du 3DS serveur
Monext vise à travers cette évolution à faciliter l'intégration du commerçant.
L'objet est de préciser dans l'attribut 'Long message' du Result le paramètre transmis par le commerçant qui est refusé par le 3DS Server. Il s'agit des erreurs '03010'.
Les commerçants utilisant l'API DirectPayment, retrouvent l'attribut 'Long message' de l'objet Result dans le message verifyEnrollmentResponse.
Ceux qui utilisent les Pages Web de Paiement ou le widget verront cette précision apparaitre à l'avenir dans le message getWebPaymentDetailsResponse suite à une prochaine livraison. La release note préviendra de la disponibilité.
Traitement des refus des demandes d'authentification incomplètes 3DSV2
Monext vise à travers cette évolution à faciliter l'intégration du commerçant.
Monext optimise le traitement de demande d'information supplémentaire du 3DSmethod pour mieux communiquer sur les erreurs en renforçant les contrôles des paramètres d’entrée de la demande d’initialisation d’authentification (verifyEnrollment).
Cette évolution ne s'adresse qu'aux utilisateurs de l'API DirectPayment.
En cas d'absence de valorisation du paramètre threeDSInfo/threeDSMethodResult, Monext retourne le code 02733 précisant que ce paramètre est absent ou vide en lieu et place du 03103 - No 3DS method and continue to authentication.
Traitement des erreurs d'authentification 3DSV2
Les retours des informations des réseaux s'affinent, Monext Online précise également ses codes retours pour optimiser les traitements 3DS.
Nous proposons donc un nouveau code retour ERROR : 03012 "No directory server" pour vous permettre d'identifier une erreur de Directory Serveur (type not found), ce qui vous permet de réaliser la demande d'autorisation.
Traitement d'un retour Attempt des Directory Serveur 3DSV2
Monext vise à travers cette évolution à augmenter le taux de conversion des commerçants utilisant l'API directe.
Actuellement lors d’un retour d'authentification de type Attempt (en 3DS V2, indique que l'authentification est acceptée en frictionless), le commerçant ne peut pas réaliser de demande de paiement.
L'objet est de pouvoir poursuivre le paiement dans ce cas de figure, en renvoyant désormais le code 03102 (qui correspondant à une authentification acceptée) dans le verifyEnrollmentResponse, afin que le commerçant puisse réaliser sa demande de paiement.
Ce comportement est similaire à celui déjà mis en place par Monext dans ses Pages Web de Paiement.
Les commerçants utilisant ce mode d'intégration bénéficient donc déjà de cette optimisation.
État temporaire du Retry
Pour optimiser le traitement du retry synchrone, Monext Online fournit un état temporaire INPROGRESS avec le code retour 02306 permettant de savoir si la session web est terminée.
Vous pourrez récupérer l'état final dès que la session web est terminée et le traitement retry est réalisé.
En mode web, vous devez appeler la demande de résultat du paiement dès la redirection ou la notification.
Le token de session des services getWebPaymentDetails ou getTransactionDetails pointera simplement sur la dernière transaction Retry réalisée.
Vous pourrez ainsi éviter les écarts de résultat si la demande de résultat de la transaction est envoyé trop tôt.
Moyen de paiement Samsung Pay
L'environnement de test (homologation) a été mis à jour.
Vous pouvez configurer votre contrat et réaliser des transactions de tests Samsung Pay.
Vous devrez installer et configurer la dernière version de l'APK, qui sera désormais mise à jour toutes les mois.
Terminal de Paiement Electronique Virtuel
Une mise à jour technique de la plateforme TPEV renforce la sécurité pour l'utilisation de ce module.
Le périmètre fonctionnel reste identique.
Historique des versions de l’API
La version 30 de l’API web services permet de proposer le traitement du PLBS du 3DSV2 avec la balise travelFileNumber et de réaliser des autorisations sans authentification avec l'object threeDSInfo (version beta).