Evolutions

From Documentation Mercanet
Jump to: navigation, search

Evolution liées à la 18R2 en date du 1er Juin 2018

Ré-essai de réponse automatique

La solution est de renvoyer plusieurs fois la réponse automatique aux clients à des intervalles prédéfinis.
Si au bout du dernier essai, le statut est toujours FAILED, alors le commerçant devra lancer un diagnostic afin d’obtenir les informations sur les transactions effectuées.

Le but est de renvoyer un certain nombre de réponses automatiques à intervalles réguliers si le statut de celle envoyée est « FAILED ».
Retry18r2.PNG
« Default » correspond à tous les autres codes HTTP possibles, non spécifiquement identifiés dansce tableau.

Une option paramétrable par offre sera créée, qui contient les paramètres de ré-essai.
Elle contiendra les paramètres suivants :

  • Nombre d’essai total (incluant le 1er essai)
  • o Ex : 5 signifie le 1er essai puis 4 ré-essais
    o 1 signifie qu’on envoie la réponse automatique sans ré-essai.

  • Le délai entre les essais (en minutes)
  • Aucune surcharge commerçante n’est disponible.
    Le nombre d’essai sera au minimum de 1 et au maximum de 5.
    Le délai sera paramétrable entre 5 min et 30 min.
    Les données par défaut sont de 5 essais, avec chaque réponse envoyée toutes les 15 minutes.

    Alignement du comportement des moteurs de lutte contre la fraude 1.0 et 2.0

    Il s’agit d’aligner la règle d’alimentation du champ complementaryCode en sortie du moteur de lutte contre la fraude 2.0 afin d’avoir un comportement similaire avec le moteur de lutte contre la fraude 1.0.

    Le champ complementaryCode doit être alimenté suivant la règle suivante :

  • Il contient la première règle décisive qui retourne un résultat négatif
  • Si aucune règle décisive ne retourne de résultat négatif, ce champ contiendra la première règle informative qui renvoie un résultat négatif.
  • Ce champ apparait dans le BO (SOE) et dans les journaux.
    Il s’agit du même comportement que l’on constate sur Sips V1.

    Evolutions liées à la 18R1 en date du 29 Janvier 2018

    Amélioration du rendu des pages de paiement Mercanet sur Mobile

    L'affichage responsive design a été optimisée pour la page de paiement Mercanet sur Mobile.
    Dorénavant, la page s'affiche entièrement sur l'écran sans avoir besoin de scroller.
    Le rendu visuel de la page Mercanet sur mobile donne le résultat suivant :
    Select mdp mobile.PNG Saisie carte mobile.PNG

    Bouton annuler sur la page de sélection des moyens de paiement

    Sur la page de sélection des moyens de paiement, le bouton Annuler a été ajouté afin d'éviter que l'acheteur clique sur le bouton précédent du navigateur pour aller sur la page précédente.
    En cliquant sur ce bouton l'acheteur revient sur la boutique du marchand qui a fait la redirection sur la page de paiement Mercanet.
    Page web select mdp cancel.PNG

    Retour d'information lors d'une erreur à l'initialisation d'une transaction

    Le marchand est informé d'une éventuelle erreur lors de l'initialisation d'une transaction utilisant le connecteur POST.
    Pour recevoir une information sur le motif de l'erreur rencontrée lors de l'appel de la page de paiement Mercanet, il faut :

    • utiliser la dernière version du connecteur POST : HP_2.19
    • renseigner dans la requête envoyée à Mercanet les champs suivants :
      • AutomaticErrorResponseInitPOST : pour recevoir une réponse automatique avec l'erreur rencontrée,
      • ManualErrorResponseInitPOST : pour rediriger l'acheteur sur cette page en cas d'erreur de l'appel de la page de paiement.

    Evolutions liées à la 17R3 en date du 9 Novembre 2017

    Création de transaction VAD sans CVV2

    La saisie du champ CVV2 pour la création d’une transaction de Vente A Distance (VAD) via le canal MOTO (Mail Order / Telephone Order) devient facultative.
    Un marchand peut réaliser une transaction en MOTO via le Back Office Marchand Mercanet.

    Modification du service getTransactionData

    La fonction getTransactionData permet de récupérer des informations relatives à une transaction existante.

    A partir de l'interface DR_WS_2.18, cette fonction permet d’avoir plus de cohérence dans le résultat obtenu :

    • Dans le champ responseCode apparaitra le résultat de la transaction recherchée (par exemple 05 si la transaction est en refus 05),
    • Un nouveau champ va faire son apparition : le getTransDataResponseCode. Celui-ci remontera le résultat de l’opération getTransactionData.
    • L’ajout du champ acquirerResponseCode permettant d’obtenir la réponse de l’acquéreur.

    Pour les interfaces versions antérieures à 2.18, le résultat du getTransactionData reste inchangé.

    Outil d'aide à la personnalisation des pages de paiement

    Afin de personnaliser sa page de paiement Mercanet, le marchand dispose d'une nouvelle interface lui permettant de :

    • modifier interactivement la personnalisation de sa page de paiement Mercanet sans connaissance informatique préalable :
      CustomPageModeSimple.png
    • prévisualiser le rendu de ses pages sur les différents matériels : Web, tablette, mobile, ...
    • déployer lui même en production la personnalisation de sa page de paiement.


    Pour disposer de cette fonctionnalité, le marchand devra en faire la demande auprès de l'assistance Mercanet.

    Amélioration du taux de transformation

    Afin d’améliorer le taux de transformation des paiements sur Mercanet, nous proposons au client de payer avec un autre moyen de paiement en cas de refus.

    Les caractéristiques principales de cette fonctionnalité sont :

    • Proposition d’un nouvel essai avec tous les moyens de paiement proposés dans la requête,
    • Proposition d’un nouvel essai sur tous les codes refus, sauf ceux assimilés à de la fraude,
    • Limitation du nombre d’essais possibles (3 par défaut),
    • Utilisation d’1 seul transactionReference (ou 1 seul transactionId) pour l’ensemble des essais.


    Pour activer cette fonctionnalité, le marchand devra en faire la demande auprès de l'assistance Mercanet.

    Modification de la marque Bancontact / Mister Cash

    Afin d’être en conformité suite aux modifications de la marque Bancontact, les mots «Mister Cash» vont être retirés du nom de la marque et le logo va être légèrement modifié.
    Le nouveau nom de la marque est désormais « Bancontact ».

    Les marchands disposant d'un ancien logo Bancontact/Mister Cash sur leur site marchand doivent les mettre à jour.
    Le logo sur les pages de paiement, d'enrôlement et sur le back office Mercanet s'affichera comme suit :
    LogoBCMC.PNG