Quantcast
Viewing all 112 articles
Browse latest View live
↧

Comment ajouter le bouton Google Pay dans Chrome ou Firefox

February 18, 2019, 1:55 pm
$
0
0
Image may be NSFW.
Clik here to view.
La plateforme de paiement PayZen durant le mois de Janvier 2019 s'est enrichi du bouton de paiement Google Pay dans les navigateurs Chrome et Firefox.

Cela veut dire que tous les utilisateurs ayant un compte Google Pay pourront payer sur votre site si vous ajoutez ce moyen de paiement.

Google a réuni dans Google Pay tous les utilisateurs des comptes YouTube, tous les comptes Android Store, etc... et permet donc à des centaines de millions de clients de payer sur votre site.

1. Comment activer Google Pay:
Tout d'abord vous devez vérifier avec votre commercial PayZen que Google Pay est inclus dans votre offre.



2. Comment créer le bouton de paiement depuis votre compte PayZen:

  • Allez dans Paramétrage Société, puis onglet Contrat.
  • Cliquez sur Créez un contrat.
La page suivant s'affiche:

Image may be NSFW.
Clik here to view.

  • Cliquez sur le logo Google Pay.

La page suivant s'affiche:

Image may be NSFW.
Clik here to view.

Automatiquement le système génère un numéro de "contrat" GooglePay": Gateway Merchant ID.
A ce stade vous devez faire 3 choses:
  • Choisir si vous voulez que le CVV/ CVV2 du porteur soit demandé via la page de sélection de carte de Google Pay. Cela ajoute une sécurité à la transaction. (A ce jour il n'y a pas de 3DSecure une fois la sélection de carte faite. Cela signifie que les paiements faits via Google Pay n'ont pas de transfert de garantie)
  • Lire et déclaré ayant lu les conditions de service de Google Pay. Tant que cette case ne sera pas cochée, le bouton Google Pay ne sera pas un moyen de paiement disponible 
  • Choisir les devises qui doivent être en correspondance avec les devises de vos contrats d'acceptation. 
Une fois la création effective, vous devez associer le contrat Google Pay à votre boutique ou à vos boutiques, via le bouton "Associer à la boutique"


Image may be NSFW.
Clik here to view.


Dans la page d'association des contrats, vous devez voir le contrat associé à la boutique:

Image may be NSFW.
Clik here to view.

3. Comment payer?

Une fois les conditions précédentes remplies, le bouton de Google Pay apparaîtra automatiquement dans la page de paiement:

Image may be NSFW.
Clik here to view.

4. Sélectionner le bouton de paiement Google Pay:

Dans une pop-in où l'url n'est pas masquée pour inciter le payeur à vérifier qu'il paye via Google Pay, apparaît pour votre compte de connexion Google, la liste des cartes associées à ce compte.
Il suffit de choisir une des cartes ou d'en ajouter une nouvelle:

Image may be NSFW.
Clik here to view.

Une fois la carte sélectionnée, pour la configuration de cette boutique, le CVV/CVV2 est demandé au porteur de la carte:

Image may be NSFW.
Clik here to view.

Dans ce cas la plateforme de paiement reçoit de Google Pay le CVV en plus des données cartes et fait alors une demande d'autorisation avec le CVV.

Si la demande d'autorisation est acceptée, le ticket fait apparaître la mention Wallet avec la valeur Google Pay.
Image may be NSFW.
Clik here to view.

Dans le Back-Office, le marchand a accès au détail de la transaction et retrouve l'information sur le wallet Google Pay:


Image may be NSFW.
Clik here to view.

Le marchand a également accès à l'onglet authentification du porteur via Google Pay. Google Pay opérant son propre contrôle de fraude qui peut aller jusqu'à la fourniture de la pièce d'identité et d'une photo de la carte bancaire.

Image may be NSFW.
Clik here to view.


Prêt à encaisser via Google Pay et à apporter à vos clients un parcours d'achat simple et rapide !!!

Suivez les nouveautés du paiement en ligne sécurisé
↧
Search

Google Pay en Polynésie Française avec l'OSB

February 20, 2019, 1:34 am
$
0
0
Image may be NSFW.
Clik here to view.
L'Océanienne de services bancaires est un acquéreur Polynésien qui commercialise PayZen by OSB auprès des marchands ayant un site e-commerce.

PayZen by OSB propose désormais le bouton de paiement Google Pay pour les paiements en XPF.  

Nous avons validé le bon fonctionnement avec un marchand qui possède un contrat d'acceptation CB (Carte Bancaire) avec saisie du CVV/CVV2.

Le marchand a commencé par créer son wallet Google Pay puis a accepté les conditions générales de Google Pay. Il a choisi de demander à l'acheteur la saisie du CVV/CVV2 sur la page de choix des cartes gérées par Google Pay.


Image may be NSFW.
Clik here to view.


Regardons maintenant comment se passe un paiement en XPF avec l'OSB:

Le bouton Google Pay apparaît sur la page des moyens de paiement disponibles. 

Image may be NSFW.
Clik here to view.

Google Pay va ouvrir une iframe avec les cartes disponibles dans le wallet de l'utilisateur si l'utilisateur est connecté (sinon il doit s'identifier):

Image may be NSFW.
Clik here to view.

La configuration de Google Pay de ce marchand impose la saisie du CVV chez Google Pay.
Une fois le CVV saisi, Google Pay transmet dans un payload (terminologie des wallets Applepay et Googlepay) à la plateforme de paiement les données cartes cryptées (carte, date d'expiration et CVV).
Avec ces données, la plateforme de paiement PayZen By OSB va pouvoir faire une demande d'autorisation en XPF. 

Dans le cas de paiement accepté, le ticket s'affiche, donne la référence de transaction CB et montre que le paiement a été initié depuis le wallet de Google Pay.

Image may be NSFW.
Clik here to view.


Dans le Back Office, l'origine du paiement est visible dans le détail de la transaction.

Image may be NSFW.
Clik here to view.



L'onglet authentification indique aussi que c'est un paiement initié depuis Google Pay:

Image may be NSFW.
Clik here to view.


Suivez les nouveautés du paiement en ligne sécurisé
↧
↧

Google Pay avec First Data Europe (EMS)

February 21, 2019, 11:51 pm
$
0
0
Image may be NSFW.
Clik here to view.
EMS est une structure du groupe Firstdata basée en Hollande.  EMS est un acquéreur multi-devises Visa et MasterCard en Europe.

La plateforme de paiement de Lyra propose une intégration native avec les Apis IPG de Firstdata.

Nous avons validé le bon fonctionnement avec un marchand qui possède un MID chez EMS basé sur l'API IPG  avec saisie du CVV/CVV2.

Le marchand a, au préalable, créé son wallet Google Pay, a accepté les conditions générales de Google Pay et demande à l'acheteur la saisie du CVV/CVV2 sur la page de choix des cartes gérées par Google Pay.


Image may be NSFW.
Clik here to view.


Regardons maintenant comment se passe un paiement en Euros avec EMS:

Le bouton Google Pay apparaît sur la page des moyens de paiement disponibles. 

Image may be NSFW.
Clik here to view.

Google Pay va ouvrir une iframe avec les cartes disponibles dans le wallet de l'utilisateur:

Image may be NSFW.
Clik here to view.

La configuration de Google Pay de ce marchand impose la saisie du CVV chez Google Pay.
Une fois le CVV saisi, Google Pay transmet dans un payload (terminologie des wallets Applepay et Googlepay) à la plateforme de paiement les données cartes cryptées (carte, date d'expiration et CVV).
Avec ces données, la plateforme de paiement de Lyra va pouvoir faire une demande d'autorisation chez EMS. 

Dans le cas de paiement accepté, le ticket s'affiche, donne la référence de transaction chez Firstdata EMS et montre que le paiement a été initié depuis le wallet de Google Pay.

Image may be NSFW.
Clik here to view.


Dans le Back-Office, l'origine du paiement est visible dans le détail de la transaction.

Image may be NSFW.
Clik here to view.


L'onglet authentification indique aussi que c'est un paiement initié depuis Google Pay:

Image may be NSFW.
Clik here to view.

Voir le parcours de paiement classique en vidéo

Suivez les nouveautés du paiement en ligne sécurisé
↧

Comprendre le time-out sur l'url de notification (IPN)

February 25, 2019, 1:55 am
$
0
0
Image may be NSFW.
Clik here to view.
A la fin du paiement, le marchand a la possibilité en fonction de différents événements ou statuts (accepté ou refusé), de demander l'appel à une url de notification instantanée (IPN en anglais comme Instant Payment Notification) sur son serveur.

Cette URL que le marchand nous demande d'appeler, est une demande d'exécution de code sur le site du marchand.

Cette URL est très importante:
  • il est toujours possible de traiter la commande via l'URL de retour, si l'acheteur revient sur le site marchand. 
  • Mais si ce dernier ne revient pas sur le site, l'unique façon de notifier le site de la fin du paiement est l'exécution de cette URL. 

Le temps de traitement sur le site marchand est à surveiller et doit être le plus rapide possible. En général un serveur bien programmé exécute ce traitement en moins de 2 secondes. Voire moins!
Cela doit être rapide car avant de donner le résultat du paiement à l'acheteur nous attendons la bonne fin de ce traitement sur le site marchand.
Cela veut dire que nous restons à l'écoute du traitement jusqu'à sa bonne fin.

Image may be NSFW.
Clik here to view.
Sauf que notre écoute a ses limites:

Au bout de 35 secondes, (ce qui est énorme et on nous a déjà demandé d'augmenter ce temps!!!) nous arrêtons d'attendre et nous envoyons un email en temps réel au marchand pour lui indiquer que son temps de traitement est très long.
En langage d'informaticiens, on dirait: "votre serveur rame grave!"

Il est très important de comprendre que ce n'est pas parce que nous arrêtons d'écouter la réponse, que cela arrête le traitement sur le serveur du marchand. Si votre traitement dure 1 mn ou plus, nous ne le savons pas. Nous sommes partis pour donner à l'acheteur le résultat de sa demande de règlement, car au bout de 35 secondes il en a surement marre d'attendre. 


Lorsque les marchands reçoivent ce mail, ils appellent fréquemment le support de la plateforme LYRA pour se plaindre de notre solution.
Sauf que le traitement est fait sur votre serveur et pas sur le nôtre.
Donc il appartient au marchand de corriger ou d'améliorer le temps de traitement.
Car l'acheteur attend et pire, pense que notre plateforme de paiement est lente!

Image may be NSFW.
Clik here to view.
Ce qui n'est pas vrai:  Le serveur du marchand est lent.

Dans le Back Office, pour chaque paiement, nous mettons à jour l'historique des événements.
Pour chaque appel à l'URL de notification, nous indiquons l'heure d'appel et le temps de traitement sur VOTRE serveur. Pas sur le nôtre.

Nous gardons aussi en mémoire les 150 premiers octets que le traitement de l'URL écrit sur le socket.
Nos modules open source essayent d'écrire un message intelligible.
Pour les implémentations propriétaires, nous recommandons d'écrire aussi un message de bonne ou mauvaise fin du traitement.


Image may be NSFW.
Clik here to view.


Image may be NSFW.
Clik here to view.
Donc surveillez vos temps de traitement, réduisez les du mieux possible et lorsque vous avez un time-out, cherchez la réponse sur votre serveur! Le support de la plateforme de paiement ne peut rien faire pour améliorer vos temps de traitement. Dans le cas de plug-ins open source, nous ne sommes pas responsables des temps de traitement de votre serveur. Cherchez le coupable chez un module tiers et surveillez l'impact de chaque modification de votre côté. Cela s'appelle faire de la gestion du changement.




Suivez les nouveautés du paiement en ligne sécurisé
↧

Savoir utiliser l'url de notification sur annulation

February 26, 2019, 1:51 pm
$
0
0

Image may be NSFW.
Clik here to view.
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'enregistre pas les abandons. Ou plus précisément, elle n'enregistre pas la transaction tant que l'acheteur n'a pas fait une action de saisie et de validation de ses données cartes.

Il est donc normal de ne pas trouver la transaction lors d'un abandon.

Le mail d'erreur vous donne la transaction concernée, mais celle-ci ne se rencontrera pas dans PayZen car les abandons sur paiement carte ne sont pas enregistrés (et donc pas facturés contrairement à certaines plateformes)

Il n'est donc pas la peine de la chercher pas dans le Back-Office de PayZen.

Suivez les nouveautés du paiement en ligne sécurisé
↧
↧

Google Pay au Chili avec Transbank

March 4, 2019, 11:45 pm
$
0
0
Image may be NSFW.
Clik here to view.
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.


Image may be NSFW.
Clik here to view.


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. 

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

Une fois reçu les données cartes cryptées depuis Google Pay (carte, date d'expiration et CVV), la plateforme analyse la configuration du marchand:

Ce marchand a une configuration qui permet à l'acheteur d'acheter en plusieurs échéances.
Comme cette configuration de paiement n'est pas connu de Google Pay, nous allons insérer une page intermédiaire avant de faire la demande d'autorisation afin de collecter les informations manquantes:

Tous les champs reçus de Google Pay sont non modifiables et partiellement visibles.

Image may be NSFW.
Clik here to view.

L'acheteur peut choisir le nombre d'échéances. Une fois cette sélection faite, nous pouvons faire une demande d'autorisation.

Dans le cas de paiement accepté, le ticket s'affiche et montre que le paiement a été initié depuis le wallet de Google Pay.

Image may be NSFW.
Clik here to view.


Dans le Back-office le marchand retrouve l'origine du paiement dans le détail de la transaction.

Image may be NSFW.
Clik here to view.


L'onglet authentification rappelle aussi que c'est un paiement initié depuis Google Pay:

Image may be NSFW.
Clik here to view.
Voir la démo en vidéo


Suivez les nouveautés du paiement en ligne sécurisé
↧

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

March 7, 2019, 1:00 am
$
0
0
Image may be NSFW.
Clik here to view.
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 facture
  • envoi de mails à votre acheteur
  • statistiques,
  • appel transporteur (logistique)
  • etc..
Autant de modules tiers que nous ne maîtrisons pas, et qui pour certains ne sont pas à jour et sont moins bien écrits que notre plug-in de paiement.

Que faire?

Chercher le coupable et pas forcément nous appeler car nous ne sommes pas le support des modules tiers. C'est déjà assez compliqué de gérer nos propres modules sans aller analyser les bugs de nos voisins. 😉

Notre documentation par exemple pour Prestashop vous donne des pistes de recherche. Et la réponse se trouve toujours dans les logs de votre serveur https et de Prestashop. 


Image may be NSFW.
Clik here to view.



En résumé, si vous avez une implémentation propriétaire, analysez vos logs et si vous avez installé un de nos modules de paiement, regardez quel module tiers est en cause. Car dans 99,999% des cas, nous n'y sommes pour rien.
Suivez les nouveautés du paiement en ligne sécurisé
↧

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

March 11, 2019, 2:00 am
$
0
0
Image may be NSFW.
Clik here to view.
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 marchand
  • les 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.

Image may be NSFW.
Clik here to view.


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é réalisés via l'API en mode incrustation.
Jusqu'à présent les services de la ville de Nice s'appuyait sur une page en redirection. Cette intégration préparée en 2018 connait un grand succès technique avec plusieurs dizaines de milliers de paiement traités par cette API révolutionnaire. 


Une fois son panier rempli, l'internaute est appelé à payer :

Image may be NSFW.
Clik here to view.


Dans ce cas, nous voyons que les champs sont directement incrustés dans la page du site marchand:

Image may be NSFW.
Clik here to view.

Il y a une reconnaissance dynamique en temps réel de la carte quelle que soit sa marque.

Une fois les données cartes saisies, la fenêtre d'authentification 3DS vient en superposition de la page marchand.

En cas de paiement refusé, on reste sur la même page et on invite l'acheteur à repayer ou à corriger ses données s'il a fait une erreur:

Image may be NSFW.
Clik here to view.

Principe d'implémentation:

3 phases basiques:
  • API REST de création de token en envoyant le montant et la devise.
  • Inclusion du code Javascript qui va construire les champs de saisie à partir du token précédemment créé. 
  • Analyse du code retour après autorisation

Remarques:

Cette API s'adapte automatiquement aux contraintes de l'acquéreur. Ce qui veut dire que les champs du formulaire s'adapte au contexte du marchand et son contrat acquéreur.
En plus des champs classiques carte, on peut demander:
  • le nom du porteur si attendu par l'acquéreur
  • le type de pièce d'identité (Amérique latine pour faire du contrôle de fraude)
  • le numéro de la pièce d'identité si attendu par l'acquéreur
  • le nombre d'échéances (Amérique latine)
  • etc
Chaque champs de l'API est en fait un champ Iframe. Donc le marchand peut personnaliser chaque champ (couleur, police, nom du champ, ..) et peut aussi définir l'ordre d'affichage de chaque champ et sa présentation (mode horizontal, sur 2 colonnes, etc..)

Cette API proposera d'ici Juin 2019 le 3DS 2.0. Les travaux d'adaptation sont en cours et sont dans la continuité de notre certification 3DS 2.0.

Votre commercial LYRA saura vous en dire plus! 

Suivez les nouveautés du paiement en ligne sécurisé
↧
Search

Google Pay et le cryptogramme visuel (CVV)

March 13, 2019, 6:30 am
$
0
0
Image may be NSFW.
Clik here to view.
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.


Image may be NSFW.
Clik here to view.

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.


Image may be NSFW.
Clik here to view.


Par ce mécanisme Google Pay enrichit vraisemblablement le profil de l'acheteur pour alimenter ses outils de contrôle anti-fraude.

Suivez les nouveautés du paiement en ligne sécurisé
↧
↧

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

March 19, 2019, 3:00 am
$
0
0
Image may be NSFW.
Clik here to view.
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 lancé le sien dans le cadre de la DSP2).

Cette interrogation n'utilise que le numéro de carte et rien d'autre parmi les données saisies par l'acheteur.
La réponse nous permet de savoir si la carte est enrôlée et de récupérer l'adresse du serveur d'authentification de l'émetteur de la carte.

Une fois que nous avons cette url, nous proposons au navigateur de l'acheteur de faire une redirection vers le serveur de l'émetteur de la carte (ACS). Dans cet appel, sont transmis le numéro de carte et la date d'expiration.

Certains ACS contrôlent la date d'expiration. D'autres non comme cela est le cas pour Atos.
Dans l'exemple ci-dessous, j'ai volontairement saisi une date erronée, mais je suis invité à m'authentifier. Pas de contrôle de date. Je ne sais pas dire si l'absence de contrôle a pour but de lutter contre la fraude et ne pas permettre aux fraudeurs de jouer avec la date. De toute façon l'ACS bloque la carte au bout de x tentatives infructueuses.

Image may be NSFW.
Clik here to view.

Par expérience, les ACS espagnols contrôlent eux la date et rejettent l'authentification en cas de date incorrecte.

Une fois authentifié, et une fois que l'internaute est revenu sur la plateforme de paiement, nous pouvons faire une demande d'autorisation en transmettant la date et le cryptogramme visuel (CVV) à l'acquéreur.
Avant cette étape le CVV n'a jamais été contrôlé, ni transmis à qui que ce soit.

En cas de CVV faux, l'émetteur utilise en général le code 59. Mais ce code n'est pas limité à ce seul cas.

Image may be NSFW.
Clik here to view.

En conclusion, le client est surement fiable, mais il s'est trompé dans sa saisie soit de la date ou plus vraisemblablement du CVV.
Suivez les nouveautés du paiement en ligne sécurisé
↧

Rembourser un paiement sur un impayé

March 21, 2019, 2:30 am
$
0
0
Image may be NSFW.
Clik here to view.

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.

Image may be NSFW.
Clik here to view.
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é.



Image may be NSFW.
Clik here to view.

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 Office, vous serez clairement informé de l'erreur et les WS de remboursement renverront également un code erreur spécifique et un message clair sur ce cas.




Disponible à partir du 28/01/2019.


Bien évidemment tout cela n'est possible que si nous recevons de votre banque les impayés et si vous avez souscrit à l'option journal des impayés dans la plateforme de paiement de LYRA.

Suivez les nouveautés du paiement en ligne sécurisé
↧

Exploiter l'url de notification sur un paiement en n fois

March 25, 2019, 1:00 am
$
0
0
Image may be NSFW.
Clik here to view.
La plateforme de paiement de Lyra vous permet de coder de multiples règles de notification.

Dans le cas de paiement en plusieurs fois, le marchand va proposer à son client un échéancier de paiement. Par défaut, nous envoyons une première notification lors du paiement de la première échéance. Mais les notifications suivantes interviennent lorsque le batch d'autorisation fait une demande d'autorisation à chaque date de l'échéancier.

Comment paramétrer les règles de notification batch:

Connectez vous au Back Office de l'application: (pour PayZen https://secure.payzen.eu/vads-merchant/)

Puis allez dans règles de notification, onglet "URL de notification"

Image may be NSFW.
Clik here to view.

Si l'URL de notification existe déjà, il vous suffit de l'activer:

Image may be NSFW.
Clik here to view.

Sinon, il vous faut la créer.
Pour ce faire en bas à gauche, sélectionner "Créer une règle"
Image may be NSFW.
Clik here to view.

Puis sélectionner comme type de règles "Appel URL de notification":

Image may be NSFW.
Clik here to view.

Suivant le type d’événements désirés, choisissez vos actions:
  • notification sur paiements autorisés par le batch 
  • et/ou notification sur paiements refusés lors de l'autorisation différée:


Image may be NSFW.
Clik here to view.

Codez alors les paramètres de l'URL de notification:
  • Nom de la règle
  • Email qui sera notifié en cas d'erreur lors de notre appel
  • Demande de rejeu de l'URL en cas d'échec (jusqu'à 4 fois). Au delà, vous devez corriger manuellement et ensuite vous pourrez toujours faire un rejeu depuis le Back Office une fois que votre problème sera corrigé. 
  • URLs que nous devons appeler en mode TEST et en mode production suivant l'API qui vous avez implémenté: Redirect ou API javascript. 

Image may be NSFW.
Clik here to view.

N'oubliez pas de vérifier que cette URL est bien active après sa création.

Suivez les nouveautés du paiement en ligne sécurisé
↧
Viewing all 112 articles
Browse latest View live
Search