Articles

Rembourser un paiement sur un impayé

Image
Ce sujet traite d'une amélioration dans le traitement des remboursements au niveau de la plateforme de paiements de Lyra.
A ce jour, nous avions un peu trop de codes d'erreurs mal détaillés et qui renvoyaient le code retour 99. Un peu un code poubelle qu'utilisait les développeurs ne prenant pas le temps de créer de nouveaux codes. Grrrrrrr!
Créer un nouveau code retour veut dire documenter plus, veut dire informer le service documentation, etc..Et parfois il est plus simple d'utiliser un code générique.
Sauf qu'un code générique n'aide pas du tout et bien sûr le commerçant appelle le support. Car un code poubelle est incompréhensible.
Pour ne plus appeler le support 😀, nous avons (enfin) défini un code spécifique pour la tentative de remboursement sur un paiement qui est en impayé.



En effet rembourser un impayé est une double peine: vous avez souffert d'un impayé et vous essayer en plus de rembourser le client.

Donc désormais en interactif dans le Back Of…

Comprendre authenfication réussie et autorisation refusée sur le code 59

Image
Le support est souvent interrogé par des marchands qui disent qu'il est impossible d'avoir un code retour 59 pour suspicion de fraude alors que le porteur s'est correctement identifié.
Voici par exemple, la réclamation d'un marchand:

Je viens de constater que le paiement d'un très ancien client parfaitement fiable avait été refusé pour "suspicion de fraude", ce qui est sans aucun doute une erreur. Avez vous plus d'information sur la raison de cette suspicion ?
D'abord nous ne faisons jamais d'erreur sur les codes retour émetteur. L'émetteur de la carte répond à la demande d'autorisation et son code retour n'est jamais modifié par la plateforme de paiement. On ne fait que le restituer.
Que fait l'authentification 3Dsecure? A partir du numéro de carte et seulement du numéro de carte, nous interrogeons le Directory Serveur (DS) de la marque de la carte (soit Visa, MasterCard,  AMEX ou bientôt le Directory Serveur du GIE CB qui a la…

Google Pay et le cryptogramme visuel (CVV)

Image
Lors de la définition du wallet Google Pay, le marchand peut décider de demander la saisie du cryptogramme visuel (CVV) à son client ou de ne pas le demander.
Avec certains acquéreurs, il est obligatoire de le demander car les "MID" sans CVV ne sont ouverts à tous les marchands.

Dans ce cas, lors du choix de carte, il est possible de demander la saisie du cryptogramme dans l'application Google Pay.
Nous avons constaté que pour mieux gérer son contrôle de fraude, Google Pay fait systématiquement un contrôle de la saisie via vraisemblablement une autorisation "0 dollars" via son prestataire de paiement.


En cas de saisie invalide, Google Pay redemande la saisie du cryptogramme visuel. Ce qui montre qu'il y a un contrôle systématique avant que Google Pay envoie ce que nous appelons la "PAYLOAD" à la plateforme de paiement. Dans ce cas, la Payload, va contenir de façon cryptée, le numéro de carte, la date d'expiration et le cryptogramme saisi.



Par…

Le Carnaval de Nice a adopté l'api Javacript pci-dss de Lyra

Image
Lancée en Septembre 2018 en phase pilote, cette API est désormais généralisée. Elle est une combinaison d'APIs REST et de codes Javascript.
Quel est l'objectif? Permettre au marchand de réaliser une intégration du paiement sans redirection et sans Iframe sur son site marchand. Et tout cela en quelques lignes de code.
Il existe 2 implémentations de l'API: les champs de saisie sont directement incrustés dans la page du site marchandles champs de saisie sont affichés dans une fenêtre en pop-in.
Comment choisir? Là, on est réellement dans la sensibilité du site marchand. Personnellement je préfère le mode pop-in car ensuite la fenêtre 3DSecure vient se superposer à la page de saisie des données de la carte. Mais l'implémentation est strictement identique. Le marchand doit juste ajouter un paramètre d'appel pour dire qu'il veut faire du mode Pop-in.



Use Case: La ville de Nice pour le carnaval a lancé un site de réservation en Janvier 2019 où 100% des paiements ont été …

Savoir traiter un HTML 500 lors de l'appel à l'url de notification

Image
Ce sujet est une source d'appel importante au support. A la fin du paiement, vous nous demandez d'appeler une URL sur votre serveur afin de transformer le panier en commande.
Dans la majorité des cas, HTML 500 est tout simplement un bug applicatif. Un bug chez vous!
Donc lors de l'appel lorsque nous détectons cette erreur HTML, nous vous envoyons un mail en temps réel pour vous prévenir qu'un problème est intervenu sur VOTRE serveur.
Et votre réflexe est d'appeler le support Lyra. Détecter l'erreur ne veut pas dire en être à l'origine.
Car nos modules ne génèrent pas ce code. Nos modules sont plutôt bien écrits.
Lorsque nous appelons l'URL, nous appelons effectivement dans le cas de Prestashop par exemple, un point d'entrée qui est celui de notre module. Mais ce n'est qu'un point d'entrée qui va déclencher de multiples traitements sur votre serveur:
mise à jour des stocksédition de factureenvoi de mails à votre acheteurstatistiques,appel…

Google Pay au Chili avec Transbank

Image
Transbank est l'acquéreur chilien qui traite les cartes de débit et de crédit au Chili.
Transbank propose plusieurs API de paiement et Google Pay ne peut être utilisé qu'avec l'API WEBPAY Completa.
Nous avons validé le bon fonctionnement de la plateforme de paiement Lyra avec un marchand qui possède l'API WEBPAY Completa avec saisie du CVV/CVV2.
Le marchand a créé son wallet Google Pay depuis le Back-office marchand, a reconnu avoir lu et accepté les conditions générales de Google Pay et a demandé la saisie du CVV/CVV2 sur la page de choix des cartes gérées par Google PAY.



Regardons maintenant comment se passe un paiement en CLP (pesos chiliens):
Le bouton Google Pay apparaît sur la page des moyens de paiement disponibles. 

Lorsque l'acheteur sélectionne le bouton Google Pay, Google Pay ouvre une iframe avec les cartes disponibles dans le wallet de l'utilisateur:

La configuration de Google Pay de ce marchand demande la saisie du CVV dans l'iframe de Google …

Savoir utiliser l'url de notification sur annulation

Image
La plateforme de paiement de Lyra permet de définir de mutliples url de notification en fonction de l’événement: Paiement accepté, paiement refusé, paiement abandonné, paiement remboursé, etc.
Plus de 15 différentes notifications sont possibles avec notre plateforme de paiement.
Lorsque nous appelons le site marchand sur l'url que celui-ci a demandé d'appeler, il arrive que le site marchand ne soit pas disponible. (erreur HTML)
Dans ce cas, nous avons un mécanisme d'alerte en temps réel et nous envoyons un mail au marchand.
L'objet du mail contient toujours le nom de la règle qui est en échec.
Il arrive donc que nous rencontrions des échecs lorsque nous appelons l'url de notification et bien sûr cela peut arriver sur l'url de notification lors d'un abandon du paiement par l'acheteur . Dans ce cas, les marchands nous appellent en nous disant qu'ils ne trouvent pas la transaction dans le Back-Office de PayZen.
La plateforme de paiement n'enregistr…