paiement PayPal Bloqué

Bonjour, merci pour le fichier de log. Il contient en fait deux problèmes différents, à deux dates différentes.

Le 2 septembre, on retrouve le problème du début du sujet : "The PayPal SDK could not be loaded from www.paypal.com/sdk/js ". C'est l'en-tête Content-Security-Policy de votre site qui bloque le chargement du script de PayPal, et c'est ce point qui empêchait les boutons de s'afficher.

Le 5 septembre, c'est autre chose, et c'est ce qui explique vos commandes qui restent en "créée". Le paiement a bien été transmis à PayPal, la carte a bien été lue (une VISA de la Banque CIC Est), et c'est la banque qui a refusé le paiement : la capture revient avec le statut DECLINED. Deux informations dans la réponse de PayPal : le code de sécurité de la carte ne correspond pas, et surtout aucune authentification 3D Secure n'a été effectuée sur ce paiement.

Les commandes restent donc en "créée" parce que l'argent n'a pas été encaissé. De ce côté HikaShop fait ce qu'il faut : il ne confirme pas une commande dont le paiement a été refusé.

Le point à vérifier est le réglage "3D Secure" de votre méthode de paiement PayPal Checkout, dans la configuration de cette méthode. C'est lui qui indique à PayPal s'il doit demander une authentification au porteur de la carte. S'il est sur "Non", ou s'il n'a jamais été renseigné, aucune authentification n'est demandée, et une banque française refuse en général un paiement par carte sans authentification. Mettez-le sur SCA_WHEN_REQUIRED, qui est le réglage adapté en Europe, et refaites un test.

Si des paiements sont encore refusés après ce changement, renvoyez-nous le log du nouvel essai : la réponse de PayPal contiendra cette fois le résultat de l'authentification, ce qui nous dira si le refus vient de la banque du client ou d'autre chose.

Bonsoir,

Ma configuration du 3D secure est déjà sur l’option « lorsque cela est requis » …

Nous avons eu une commande cet après midi et aucun problème de multiplication de commandes créés.

A suivre

Bonjour,

Ok. Alors peut être que c'était l'utilisateur qui avait renseigné un mauvais code de sécurité (les 3 chiffres au dos de la carte).
A voir avec les prochaines commandes.
Gardez l'option "debug" activée dans la méthode de paiement, et si vous avez à nouveau des problèmes, décrivez les et fournissez le log par email et nous étudierons à nouveau la situation à la lumière de ces nouvelles informations.

Bonjour,

De nouveau multiplication de commande, voici ce que me rapporte le client :
Je suis arrivé à l’étape de paiement par CB et le popup m’invitant à valider sur mon smartphone est resté figé. J’ai néanmoins reçu la notification et validé le paiement.

La fenêtre étant toujours figée, j’ai rafraîchi et là j’ai reçu 2 mails de notification avec 2 numéros de commande différents : B8Q7Y2 et B8Q7Z3. Je ne sais pas si le paiement a été validé pour l’une des 2.

Je vous envoie les logs à nouveau.
Merci

Bonjour,

Le fichier de log que j'ai est exactement le même que celui du 6 septembre : il s'arrête au 5 septembre et ne contient rien sur les commandes B8Q7Y2 et B8Q7Z3. Soit l'option "debug" de la méthode de paiement a été désactivée entre temps, soit c'est l'ancien fichier qui a été joint à l'email. Pouvez-vous vérifier que le debug est toujours activé dans la méthode de paiement PayPal et me renvoyer le fichier ?

En attendant, sur la multiplication des commandes, le mécanisme est le suivant : la page qui affiche les boutons PayPal est une adresse que le navigateur peut recharger, et à chaque rechargement le panier est retransformé en commande. Quand votre client a rafraîchi sa page parce que la fenêtre 3D Secure restait figée, une deuxième commande a donc été créée à partir du même panier, d'où les deux emails et les deux numéros. Cela n'a pas de rapport avec PayPal lui-même, mais c'est avec un paiement par carte que le client a une raison de rafraîchir.

De notre côté, nous allons rajouter une amélioration pour la prochaine version : un rechargement de cette page réaffiche la commande déjà créée au lieu d'en créer une seconde, et si le paiement est arrivé pendant que la page était ouverte, il renvoie sur la page de remerciement pour que le client ne puisse pas payer deux fois. Donc même si il y a un problème avec la méthode de paiement et que le client doit rafraichir la page pour une raison ou une autre, vous n'aurez plus de double commandes.

Bonjour,

1/ Hier, suite à une annulation de commande, je vous ai fait parvenir par mail les derniers logs afin d'en connaitre la raison.
2/ Maintenant 4 commandes créées sans aboutir au paiement PayPal...

Merci

Bonjour,

Merci pour ce nouveau log. Le paiement de la commande 875 a bien été refusé par la banque du client: PayPal renvoie la capture avec le statut DECLINED et le code 5650, qui signifie "authentification forte requise". Et effectivement, la réponse de PayPal ne contient aucun résultat d'authentification 3D Secure pour cette transaction: aucune authentification n'a été demandée au porteur de la carte, et c'est exactement pour cette raison que l'émetteur de la carte (une American Express française) a refusé. Le code de sécurité et l'adresse étaient bons cette fois ci.

Avec le réglage "lorsque cela est requis", c'est PayPal qui décide s'il faut authentifier le porteur, et ici il a décidé que non. Passez le réglage 3D Secure de la méthode de paiement sur SCA_ALWAYS: l'authentification sera alors systématiquement demandée, ce qui devrait éviter ce refus avec les cartes françaises.

Ce log nous a aussi montré un point à améliorer de notre côté, et je vous remercie de nous l'avoir envoyé. Quand la banque refuse ainsi le paiement, PayPal renvoie quand même la commande avec le statut "terminée" et ne signale le refus que sur le paiement lui même. Le plugin ne regardait que le statut de la commande: il affichait donc le message de remerciement à votre client alors qu'aucun argent n'avait été encaissé, puis la notification qui suit relisait la commande chez PayPal et passait votre commande en annulée. C'est ce que vous avez constaté. Dans la prochaine version, la commande n'est plus annulée et le motif donné par PayPal est écrit dans l'historique de la commande. Vous pourrez donc voir vous même qu'un paiement a été refusé pour authentification manquante, pour provision insuffisante ou pour un code de sécurité erroné, sans avoir à nous envoyer les logs. Et dans le cas précis de ce refus pour authentification manquante, le plugin renvoie automatiquement la carte avec l'authentification forcée: le client reçoit alors la demande de validation de sa banque au lieu de perdre sa commande. Le réglage SCA_ALWAYS reste malgré tout à faire dès maintenant, puisqu'il demande l'authentification dès le premier essai.

Bonjour,

Merci pour votre retour un dimanche... Je viens de mettre le paramètre 3D SECURE à l'option "toujours" et on y verra un peu plus clair. Le client m'affirme qu'il a fait le paiement et que c'était accepté (à confirmer) par sa banque mais de mon coté je n'ai pas de commande confirmée donc payée. Il va vérifier et reviendra vers moi...

A suivre

Bonsoir

1/À nouveau une commande qui n’aboutit pas et je ne sais pas pourquoi (peut-être rien à voir)…Du coup, j’ai toujours un doute.
Je vous fais parvenir les logs demain matin

2/ ce matin, encore une multiplication de commandes créés suite à des tentatives de paiement par carte…sans arriver au paiement PayPal du même client d’hier avant le paramétrage de « toujours » au 3D secure. Apparemment il aurait eu accès au 3D Secure de sa banque, acceptation de la transaction mais cela reste figé et le paiement ne se fait pas > je vous fais suivre les logs.

Cela devient compliqué

Merci

Bonjour,

Merci pour les logs. Ils montrent un changement net le 20 septembre. Jusqu'à la commande 875, les boutons PayPal s'affichaient normalement. À partir de la commande 876, à chaque tentative et sur tous les appareils (iPhone comme PC Windows), le script de PayPal signale qu'il a détruit ses propres boutons juste après son chargement ("zoid destroyed all components"), et le bouton PayPal n'apparaît plus : seuls les champs de carte restent affichés. Ce message apparaît en général quand le script de PayPal est chargé deux fois sur la même page. Le même plugin sur notre site de test affiche ses boutons sans cette erreur, donc quelque chose de propre à votre page est en jeu et nous devons la voir.

Pour les commandes du 20 :
- 876 à 879 : le même client sur iPhone, quatre essais en cinq minutes. Chaque nouvel essai crée une nouvelle commande, d'où la multiplication. Sur la 879, il a saisi sa carte et la validation 3D Secure de sa banque s'est lancée, mais rien n'est revenu ensuite vers le site : ni validation ni refus.
- 880 : le client sur PC est resté trois minutes sur la page de paiement sans qu'aucun paiement ne parte.

Pouvez vous passer une commande jusqu'à la page de paiement PayPal (sans payer), puis enregistrer cette page avec Ctrl+S (ou Cmd+S sur Mac) en choisissant "Page web complète", et nous envoyer le fichier .html obtenu par email ? Ça nous permettra de voir ce qui charge le script de PayPal une deuxième fois.

Fait et envoyé !

Pour info la commande 882 et 881 contiennent des serials...
Déjà pour le 874 du 18/09 j'avais eu un problème.
Merci pour les explications

Bonjour,

Merci pour la page, elle nous a permis de trouver le problème. Sur votre site, le panier est encore rempli quand le client arrive sur la page de paiement, et le module panier y affiche le bouton PayPal express. Ce bouton charge une deuxième fois le script de PayPal sur la page, ce qui supprime les boutons de paiement de la page : il ne reste alors que les champs de carte. C'est ce qui s'est passé pour les commandes 876 à 880, et c'est pour cela que votre client a recommencé plusieurs fois, en créant à chaque fois une nouvelle commande.

Nous avons corrigé le plugin pour que le bouton express ne s'affiche plus sur la page de paiement. Téléchargez à nouveau le paquet HikaShop 6.6.0 depuis votre compte et installez le par dessus votre version actuelle. En attendant, vous pouvez aussi désactiver l'option du bouton express sur le panier dans les paramètres de votre méthode de paiement PayPal Checkout : les boutons de la page de paiement devraient alors s'afficher de nouveau.

Merci encore pour votre retour complet et rapide!

Est-ce normal que le panier soit toujours rempli ? Est ce gênant de ne pas avoir les boutons de paiement PayPal si on veut régler par carte et donc saisir ses numéros ?
Je ne sais même pas pourquoi cette option est activée mais je vais l’enlever de suite et charger le nouveau package et je reviens vers vous si j’ai d’autres interrogations.

Je vais dire au client d’essayer à nouveau.

Merci encore
Cordialement,

Bonjour,

Encore une multitudes de commandes et paiement Paypal impossible. Ce client passe régulièrement des commandes...sans aucun problème d’habitude.

« La fenêtre d’authentification sécurisée n’apparaît ni sur ma tablette ni sur mon téléphone » est le message qu’il m’a laissé.

J'envoie les logs..

Cela commence à devenir un peu gênant, je loupe beaucoup de commandes…

Version : HikaShop Starter 6.6.0 [2609231355]

Merci

Bonjour,

Merci pour les logs. D'abord une bonne nouvelle : depuis la mise à jour, l'erreur "zoid destroyed all components" a disparu. Les champs de carte s'affichent et le paiement arrive bien jusqu'à PayPal.

Le problème de ce matin est différent. Votre client a payé avec une carte American Express professionnelle. Pour les commandes 884 et 886, PayPal a bien reçu la carte, puis la banque a refusé le paiement avec le code 5650, qui veut dire "authentification requise". Et dans la réponse de PayPal, aucune authentification 3D Secure n'a été faite, alors que votre méthode de paiement la demande maintenant à chaque paiement. Autrement dit, PayPal n'a pas ouvert la fenêtre de la banque pour cette carte, ce qui correspond exactement à ce que votre client décrit. Sur l'ensemble de vos logs depuis le 2 septembre, aucune authentification 3D Secure n'est allée jusqu'au bout.

Cette fenêtre est ouverte par le script de PayPal, pas par HikaShop. Nous allons regarder de notre côté pourquoi PayPal ne l'affiche pas. Vous pouvez aussi interroger le support de PayPal en leur donnant ces deux références de paiement : 2LB582675D826732N et 0H6537347T855204N. La question à leur poser : pourquoi le 3D Secure n'a pas été déclenché sur cette carte American Express alors que la contingence SCA_ALWAYS est envoyée. Demandez-leur aussi si l'authentification American Express (SafeKey) est bien activée sur votre compte : chez Braintree, la société sœur de PayPal, elle doit être activée à la demande, et c'est peut-être aussi le cas chez PayPal.

En attendant, votre client peut payer avec le bouton PayPal plutôt qu'avec les champs de carte. Il peut s'y connecter à son compte PayPal, ou choisir d'y payer par carte : dans ce cas, c'est la page de PayPal qui gère l'authentification de la banque.

Pour vos questions précédentes :
- Oui, il est normal que le panier reste rempli tant que le paiement n'est pas confirmé. Cela permet au client de réessayer sans tout ressaisir. Il est vidé une fois le paiement confirmé.
- Non, désactiver le bouton express sur le panier ne gêne pas le paiement par carte. Les boutons PayPal et les champs de carte restent affichés sur la page de paiement.

Chaque tentative crée une commande qui reste en "créée" si le paiement n'aboutit pas. Vous pouvez supprimer ces commandes sans risque.

Merci pour ces détails..

Je pense que c'est depuis la 6.6.0 que j'ai ces difficultés, après plusieurs paramètres étaient mal configurés mais cela fonctionnait…Ma boutique ne génère pas trop de commandes mais en septembre ce fut assez intense et souvent en échec et donc perte de CA car souvent le client ne retente pas...

Est-ce que je dois attendre un retour de votre part ?

A voir donc...
Merci

Bonjour,

De notre côté, nous avons passé la journée sur votre problématique mais tous nos tests sont inconcluants. Peu importe ce que nous essayons, le plugin fonctionne correctement.
De plus, la majorité de nos utilisateurs sont aussi sur PayPal, et il y a des des centaines de marchands avec leur boutique sur la 6.6.0 avec PayPal.
Pour moi, le problème est plutôt à chercher du côté de l'activation des cartes american express sur votre compte PayPal et c'est spécifique à ce client à vous en particulier qui utilise une AMEX, comme je disais dans mon message précédent.

Bonsoir

Avec le recul, déjà dans la semaine, vous m’aviez dit que le problème d’un autre client venait d’une American Express Française. Il doit effectivement y avoir un lien.

Je ne doute pas que beaucoup utilisent ce plugin sans problème mais ce dernier client l’a déjà utilisé et cela a fonctionné, c’est un client qui utilise ma boutique fréquemment. D’ailleurs il vient d’essayer de payer à nouveau sa commande d'hier matin et nouvel échec. Je lui ai dit de passer par le bouton PayPal mais je ne sais pas si il l’a fait. Je vous fais suivre les logs (1er mail de ce matin).

Tentative ce matin, je lui ai indiqué de ne pas utiliser une AMEX (mail log2) je ne sais pas si c'est le cas mais cela a fonctionné !

Je vais chercher avec PayPal mais difficile à contacter…

Merci

Bonjour,

Je vous transmets les copie d'écran du client et ses explications.

Je vous laisse en pièce jointe les étapes de paiement, le bouton Paypal n'apparait pas, en tout cas je ne le vois plus, il n'y a plus que la possibilité d'entrer un numéro de carte, la vérification Amex me demande un code à rentrer sur une fenêtre pop up qui est censée apparaitre mais vous pourrez constater sur la capture où j'ai masqué mon numéro de carte que la pop up est en cours d'apparition sauf que l'écran n'évolue plus et stagne dans cet état,(Cadre rouge photo 4) je reçois bien le code mais je n'ai pas moyen de l'inscrire sur la pop up car elle reste transparente.
Etant donné que pour les plus petits montants je n'ai pas systématiquement de code à communiquer j'ai tenté de réduire le montant, mais ce que je ne comprends pas c'est que la fenêtre est quand même apparue, j'ai reçu le code, après plusieurs minutes à attendre de voir si le pop-up allait apparaitre j'ai fermé la partie en surbrillance (croix en haut à droite) et là, message de commande validée + mail avec les tickets.
Un vrai mystère ...

Alors j'ai fait un test et effectivement je n'ai pas les boutons PayPal même si ils sont paramétrés...

A voir

Bonjour,

Merci pour les nouveaux logs et les captures. Il y a en fait deux problèmes distincts.

1. Le bouton PayPal invisible

Il vient du template du site (J51 Nina). Son fichier media/templates/site/j51_nina/css/animate.min.css contient cette règle, qui rend transparent tout élément portant la classe "visible" : PayPal utilise précisément cette classe sur le cadre de son bouton : il est bien chargé mais reste totalement transparent. Pour corriger, ajoutez ce CSS dans le champ de CSS personnalisé du template (ou dans un fichier custom.css) : Nous l'avons testé sur votre page de paiement : le bouton PayPal réapparaît avec cette règle.
C'est un souci à remonter au développeur du template.

2. La fenêtre de vérification AMEX qui reste transparente

Celle-ci n'est pas touchée par la règle du template (elle est affichée dans un cadre séparé où le CSS du site ne s'applique pas), donc la cause est ailleurs. Ce que montrent les logs :
- 24/09, 390 € : refusé avec le code 5650 (authentification exigée par AMEX et non effectuée).
- 25/09, 130 € : accepté après la fermeture de la fenêtre, sans authentification.
PayPal n'a reçu aucun résultat d'authentification sur ces deux paiements. Le fait que le client reçoive le code montre que la vérification SafeKey est bien active et démarre, mais la fenêtre de saisie ne s'affiche pas dans son navigateur.

Malheureusement, difficile de conclure avec cela. L'authentification 3DS est quelque chose qui se passe du côté de PayPal. Il va falloir voir plus de logs pour mieux comprendre le souci.

En attendant, une fois le bouton PayPal de nouveau visible, les clients AMEX devraient pouvoir payer via ce bouton : l'authentification se fait alors dans la fenêtre de PayPal, et non dans le formulaire de carte de la page.