Difficultés avec le paiement récurrent

  • Posts: 235
  • Thank you received: 4
9 months 3 weeks ago #296074

-- HikaShop version -- : 3.5.1
-- HikaSerial version -- : 2.2.0
-- Joomla version -- : 3.8.8
-- PHP version -- : 7.1

Bonjour,

J'ai paramétré un produit lié à un plan pour une souscription d'un jour renouvelable tous les jours. Le plugin de paypal_recurring (avec le "_") est actif.
Quand j'achète le produit, il me propose bien le plugin Paypal recurring en indiquant "1 day" (cf. captures). Il me redirige ves paypal, le paiement est fait et accepté, la commande passe en confirmed (notif reçue) et la souscription devient active. Ok.
Mais le renouvellement ne se fait jamais malgré tous mes essais.
Quand je consulte le dashboard de Paypal, je n'ai pas l'impression que le paiement est enregistré en tant que "installment" par Paypal. Il apparaît comme un paiement "une fois" contrairement aux essais que j'avais fait avec l'ancien plugin (paypalrecurring sans le "_").
L'association produit souscription est de type "create then renewal".
Ci-joint le fichier log du debug avec la trace de mon essai précédent avec le mode debug actif. Je l'ai désactivé pour mon dernier essai au cas où cela gênerait (le mode debug empêche le transfert auto vers la page paypal en fin de checkout).
Par ailleurs, quand je clique sur le lien "renouveler" de la liste de mes souscriptions quand le statut est expiré, il me renvoie vers le catalogue avec un message "le panier est vide". Il ne fait pas le renouvellement.
Le cron est actif et fait son boulot (hikasub checked).
Le paramètrage indique qu'il est possible de renouveler une souscription avant et après son expiration (1 jour).

Comment faire pour comprendre ce qui se passe ?

Laurent

Please Log in or Create an account to join the conversation.

  • Posts: 235
  • Thank you received: 4
9 months 3 weeks ago #296075

Suite avec le paramètrage du plugin et le fichier log

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 65715
  • Thank you received: 9593
  • MODERATOR
9 months 3 weeks ago #296115

Bonjour,

Ne connaissant pas bien le code de PayPal Recurring, je ne vais pas pouvoir vous aider sur cette question.
Jérome, le spécialiste du sujet est en vacances cette semaine, donc je crains qu'il va falloir attendre son retour la semaine prochaine pour avancer vraiment.
Une chose quand même que je recommanderais, c'est d'activer l'option "debug" de la méthode de paiement et de refaire un test.
Le log de paiement devrait ainsi contenir un peu plus d'information sur ce qu'il se passe.

Please Log in or Create an account to join the conversation.

  • Posts: 235
  • Thank you received: 4
9 months 2 weeks ago #296372

Friendly bump, donc ;-)

Please Log in or Create an account to join the conversation.

  • Posts: 23435
  • Thank you received: 3643
  • MODERATOR
9 months 2 weeks ago #296405

Bonjour,

Le fichier de log indique que le paiement envoyé à Paypal n'est pas récurrent.
Nous devrions avoir la variable "cmd" à "_xclick-subscriptions" ainsi que des paramètres liés au recurring.

La raison pour laquelle le plugin ne prendrais pas en compte le recurring est relative au contenu des "Payment Options" et spécifiquement, le stockage de l'unité de durée (qui doit être "d", "w", "m" ou "y").

Dans le plugin ( plugins/hikashoppayment/paypal_recurring/paypal_recurring.php ) vous trouverez la ligne de code

if(!empty($order->cart->paymentOptions['recurring'])) {
Je vous invite à la modifier afin d'avoir
if($this->payment_params->debug)
	$this->writeToLog($order->cart->paymentOptions);
if(!empty($order->cart->paymentOptions['recurring'])) {

Ainsi, vous aurez une nouvelle entrée dans le log de paiement avec les données du "paymentOptions" et nous en saurons plus sur la raison pour laquelle le plugin considère qu'il n'y a pas de recurring pour la commande.

Cordialement,

PS: Vous avez bien fait de répondre. Puisque le dernier message était de Nicolas et vous demandais des informations, le ticket n'était donc plus ouvert.


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 235
  • Thank you received: 4
9 months 2 weeks ago #296445

Bonjour,

J'ai d'abord mis à jour le plugin suite à la modif sur l'erreur SQL lors de l'affichage des souscriptions en front (autre post).
Ensuite j'ai réactivé le mode debug sur le plugin paypal_recurring puis j'ai fait la modif.
Ne trouvant aucune info sur "PaymentOptions" dans le log suite à cette modif, j'ai modifié l'instruction de debug pour afficher l'objet 'cart' complet ($order->cart). Là, j'ai bien le print_r de l'objet mais pas de trace de "paymentOptions". Par contre, il y a des infos sur le mode de paiement (cf. snapshots).
Donc effectivement, dans le code, la variable $recurring_unit n'est jamais positionnée et donc aucune info de paiement récurrent.

Par ailleurs, dans mes essais, j'ai fait un paiement réel complet (en mode debug) et n'ai jamais reçu la notification permettant de passer la commande en "confirmée". J'ai l'impression que le mode debug empêche la notification d'arriver.

Enfin, quand on annule, le paiement sur la page de login de Paypal (annuler et retour au site), il revient bien au site et sur la bonne page (cancel_url) mais ne passe pas la commande en "canceled". Elle reste en "create". Ceci, toujours en mode "debug". Je ferai des essais plus complets sans le mode "debug" une fois qu'on aura réglé le pb des paiements récurrents.

Laurent

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 23435
  • Thank you received: 3643
  • MODERATOR
9 months 2 weeks ago #296471

Bonjour,

Afin de s'assurer de la lecture de l'information, nous pouvons utiliser le code suivant

		$recurring_data = false;
		if(!empty($order->cart->paymentOptions['recurring']))
			$recurring_data = $order->cart->paymentOptions['recurring'];
		else if(!empty($order->cart->order_payment_params['recurring']))
			$recurring_data = $order->cart->order_payment_params['recurring'];
		else if(!empty($order->order_payment_params['recurring']))
			$recurring_data = $order->order_payment_params['recurring'];
		if(!empty($recurring_data)) {
			$recurring_unit = substr($recurring_data['duration'], -1);
J'avoue être très surpris que vous n'ayez pas "paymentOptions" puisque le trigger de gestion du recurring doit être appelé au préalable.

La partie "cancel" passe par le core d'HikaShop et ce n'est pas le plugin qui s'occupe de passer la commande en annulée.
Il faudra donc regarder votre configuration HikaShop et tester avec le plugin "paypal classique".

Quand à la non confirmation ; je suis surpris puisque vous aviez bien de la configuration précédemment.
Toujours est-il que si vous avez une notification, vous devriez au moins avoir de la trace dans le fichier de log de paiement.

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 235
  • Thank you received: 4
9 months 2 weeks ago #296486

J'ai du faire des modifications plus profondes car $order->cart->order_payment_params n'est pas un tableau mais un objet et d'autre part le paymentOptions est utilisé un peu plus bas pour remplir les champs de l'interface PayPal.
J'ai donc actuellement cela :

		$recurring_unit = false;
		if($this->payment_params->debug)
			$this->writeToLog("Debug : paymentOptions by Apchea");			
//			$this->writeToLog($order->cart->paymentOptions);
			$this->writeToLog($order->cart);			
//		if(!empty($order->cart->paymentOptions['recurring'])) {
//			$recurring_unit = substr($order->cart->paymentOptions['recurring']['duration'], -1);
		$recurring_data = false;
		if(!empty($order->cart->paymentOptions['recurring']))
			$recurring_data = $order->cart->paymentOptions['recurring'];
		else if(!empty($order->cart->order_payment_params->recurring))
			$recurring_data = $order->cart->order_payment_params->recurring;
		else if(!empty($order->order_payment_params['recurring']))
			$recurring_data = $order->order_payment_params['recurring'];
		if(!empty($recurring_data)) {
			$recurring_unit = substr($recurring_data['duration'], -1);
		if(!in_array($recurring_unit, array('d','w','m','y')))
				$recurring_unit = false;
		}

		if(!empty($recurring_unit)) {
			$vars['cmd'] = '_xclick-subscriptions';
			$vars['txn_type'] = 'subscr_payment';
			$vars['item_name'] = JText::_('CART_PRODUCT_TOTAL_PRICE');
			$vars['a3'] = number_format($order->cart->full_total->prices[0]->price_value_with_tax, 2, '.', '');
//			if(!empty($order->cart->paymentOptions['recurring']['value'])) {
			if(!empty($recurring_data['value'])) {				
				$vars['a1'] = number_format($order->cart->full_total->prices[0]->price_value_with_tax, 2, '.', '');
//				$vars['p1'] = (int)$order->cart->paymentOptions['recurring']['duration'];
				$vars['p1'] = (int)$recurring_data['duration'];				
				$vars['t1'] = strtoupper($recurring_unit);

//				$vars['a3'] = $order->cart->paymentOptions['recurring']['value'];
				$vars['a3'] = $recurring_data['value'];				
			}
//			$vars['p3'] = (int)$order->cart->paymentOptions['recurring']['duration'];
			$vars['p3'] = (int)$recurring_data['duration'];
			$vars['t3'] = strtoupper($recurring_unit);
			$vars['src'] = 1;
			$vars['sra'] = !empty($this->payment_params->reattempt) ? 1 : 0;
		}

		$this->vars = $vars;

Ce qui me donne un dump plus pertinent pour un abonnement :
<pre>Array
(
    [cmd] => _xclick-subscriptions
    [upload] => 1
    [business] => xxxxx@yyyy.fr
    [receiver_email] => xxxxx@yyyy.fr
    [invoice] => 685
    [currency_code] => EUR
    [return] => https://www.yyyy.fr/index.php?option=com_hikashop&ctrl=checkout&task=after_end&order_id=685&Itemid=669
    [notify_url] => https://www.yyyy.fr/index.php?option=com_hikashop&ctrl=checkout&task=notify&notif_payment=paypal_recurring&tmpl=component&lang=fr&Itemid=669
    [cancel_return] => https://www.yyyy.fr/index.php?option=com_hikashop&ctrl=order&task=cancel_order&order_id=685&Itemid=669
    [undefined_quantity] => 0
    [test_ipn] => 1
    [shipping] => 0
    [no_shipping] => 1
    [no_note] => 
    [charset] => utf-8
    [rm] => 2
    [bn] => HikariSoftware_Cart_WPS
    [address_override] => 1
    [first_name] => Laurentéèçùü
    [last_name] => Colzzzzzzz - APCHEA
    [address1] => fghdfg
    [address2] => 
    [zip] => dfg
    [city] => dfg
    [state] => 
    [country] => FR
    [email] => colzzzzzz@apchea.com
    [night_phone_b] => 464645
    [item_name_1] => Abonnement mensuel - YYYY - Annuaire des prescriptions / Articles / Statistiques
    [item_number_1] => ABM_test
    [amount_1] => 0.10
    [quantity_1] => 1
    [txn_type] => subscr_payment
    [item_name] => Prix total
    [a3] => 0.10
    [p3] => 1
    [t3] => D
    [src] => 1
    [sra] => 1
)
</pre>

Et là, cela génère bien un abonnement dans l'interface PayPal conforme aux données Hika et se déroulant sans anicroche.

Par contre en mode debug, pas de passage auto sur l'interface Paypal, il faut cliquer sur le bouton pour passer du last chekout step à l'url PayPal de paiement.

De même on ne reçoit aucune notification. Pas de traces dans les logs non plus. J'ai donc désactivé le mode debug au cas où mais cela ne change rien pour les notifications. Par contre, il passe automatiquement du dernier step du chekout à Paypal.

Côté "fournisseur", le compte est bien crédité par paypal et l'historique des IPN semble "normal" (cf. captures).

J'ai noté aussi que lorsque j'affiche les souscriptions actives dans le dashboard en front (qui fonctionne maintenant :-) ), le bouton "renouveler" contient cette url :

www.yyyy.fr/fr/achat/mon-compte/subscrip...ption-16/product-252 .

Cela correspond bien à la souscription concernée (16) et au produit (252). Par contre en cliquant dessus, cela affiche le catalogue général publique et un message "le panier est vide" sans autre info et sans que la souscription ait été renouvelée (mise au panier).

La seule config "spéciale" que je pourrais avoir c'est que le produit n'est pas public. Il est restreint au "super-user" ....

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 23435
  • Thank you received: 3643
  • MODERATOR
9 months 2 weeks ago #296493

Bonjour,

Par contre en mode debug, pas de passage auto sur l'interface Paypal, il faut cliquer sur le bouton pour passer du last chekout step à l'url PayPal de paiement.

Oui c'est tout à fait normal. En mode debug, puisque des informations sont affichées il n'y a pas de validation automatique du formulaire.

De même on ne reçoit aucune notification

Je crains ne pas pouvoir vous dire grand chose. L'url de notification est bien dans le log et même dans votre interface de Paypal mais celui ci indique n'avoir fait aucune tentative.
Le soucis me semble donc être du côté de Paypal et non du plugin.
CF : developer.paypal.com/docs/classic/ipn/in...ifications-on-paypal

La seule config "spéciale" que je pourrais avoir c'est que le produit n'est pas public. Il est restreint au "super-user" ....

En effet, HikaSubscription ne fait pas les tests pour vérifier les ACL au niveau des produits et c'est probablement la source de ce soucis.
Je vais me planifier quelques tests supplémentaires afin de gérer ce genre de cas.

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 235
  • Thank you received: 4
9 months 1 week ago #296667

Bonjour,

Effectivement, les IPN étaient désactivées côté Paypal. Je reçois maintenant la notification et le processus "hika" se déroule normalement.
J'attends de voir si les renouvellements se passent bien.

Par contre, je n'arrive pas à faire en sorte qu'un paiement annulé entraîne l'annulation de la commande. L'url de retour est correcte, cela affiche la page d'annulation sur le site (article Joomla) mais la commande reste à "create" dans Hikashop.
Sur un paiement CB via ATOS, l'annulation se passe normalement (page affichée et commande qui passe en "cancel").
Je ne vois pas bien quel paramètre général serait concerné puisque l'annulation se passe bien avec le plugin ATOS. Dans quel module pourrais-je mettre une "trace" pour essayer de comprendre ce qui se passe ?

Merci

Laurent

Please Log in or Create an account to join the conversation.

  • Posts: 23435
  • Thank you received: 3643
  • MODERATOR
9 months 1 week ago #296669

Bonjour,

La partie "cancel" passe par le core d'HikaShop et ce n'est pas le plugin qui s'occupe de passer la commande en annulée.
Il faudra donc regarder votre configuration HikaShop et tester avec le plugin "paypal classique".

Tout se passe dans HikaShop (controlleur Order, function "cancel_order") et vous pouvez vérifier la configuration de status de commande afin de bien vous assurer que vous pouvez annuler une commande "created/pending" de Paypal recurring.

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 235
  • Thank you received: 4
9 months 1 week ago #296725

Bonjour,

Effectivement, pour l'annulation, cela venait du paramétrage des statuts (cf. copie écran). Pour un produit payé en CB via Atos, l'annulation se passait bien, mais pour le paypal_recurring il faut que la commande "created" soit "cancellable".... Je ne comprends pas d'où vient la différence de comportement mais toujours est-il que cela fonctionne. J'ai pu trouver et comprendre cela en traçant le comportement de la fonction cancel_order. Merci.

Par contre, je ne comprends pas comment s'articule le payment récurrent et les souscriptions. Suite à ma commande d'hier qui s'était bien passée (retour IPN faisant passer la commande en "confirmed" et la souscription en "active"), j'ai attendu le déclenchement de la récurrence d'aujourd'hui. Côté HikaShop, le cron est passé et à basculer la souscription en "expired" à l'heure dite. Il ne semble avoir rien fait d'autre. En tout cas pas trace dans le log.
Côté Paypal, un paiement a été déclenché et un IPN reçu sur le site (je pense car le fichier log du mode debug n'enregistre pas systématiquement la date et l'heure). Par contre, aucune mise à jour de quoi que ce soit côté "hika". Pas de nouvel historique dans la commande d'origine, pas de nouvelle commande, pas de mise à jour de la souscription. Le numéro de la transaction d'aujourd'hui communiqué par Paypal n'apparaît nulle part.

Est-ce l'IPN reçu de paypal qui doit déclencher une mise à jour de la souscription (la passer de "expired" à "active") ? Dans ce cas, est-ce qu'une nouvelle facture est générée ? Comment ? Dans mon cas, rien ne se passe.

Où est-ce le cron qui doit déclencher une nouvelle commande si la souscription est expirée si, comme c'est le cas, elle n'est pas encore "closed" ?

Actuellement, du côté paypal, tout semble "normal". Il prélève la somme et indique que la notification a été faite. L'abonnement existe dans mon dashboard Paypal et correspond aux informations transmises dans la commande initiale. Paypal déclenche un paiement automatique "comme il faut".
Mais côté "Hika", rien n'est mis à jour. ni la commande, ni la souscription.... Je suppose que c'est la notification de Paypal qui devrait entraîner des modifs dans hika (mise à jour de la souscription,

Par ailleurs, comme expliqué précédemment, le lien "renouveler ma souscription" ne déclenche pas une mise au panier du produit suivi d'une possibilité de payer. Il se contente d'afficher un message J! "le panier est vide". Problème d'ACL ? Merci de m'aider à identifier le module au sein duquel je pourrais "tracer" ce qui se passe pour tenter de comprendre.

Laurent

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 23435
  • Thank you received: 3643
  • MODERATOR
9 months 1 week ago #296758

Bonjour,

L'IPN de paypal va être un peu spécifique car il doit contenir des informations de récurrence.
Ces informations sont récupérées par le plugin qui va appeler une fonction spéciale dans HikaShop permettant de créer une commande récurrente (une copie de la commande avec seulement les produits concernés).
Cette nouvelle commande est ensuite ajoutée à la souscription de l'utilisateur et sa confirmation va augmenter la date de fin de celle-ci.

Si vous n'avez pas les informations de l'IPN du côté HikaShop ; il serait intéressant de regarder dans le log du côté de Paypal.
En fonction de l'heure et de vos paramètres, il est possible que cela puisse bloquer (si vous n'autorisez pas le renouvellement après expiration, si jamais l'IPN est arrivé après celui ci).

N'ayant pas les détails sur votre produit et pourquoi vous ne pouvez pas faire le renouvellement ; il va être difficile pour moi de fournir des réponses. Mais il y a une possibilité pour que ce soucis puisse être aussi le même soucis que pour le renouvellement via IPN.
Ce renouvellement se contente d'ajouter le produit détecté comme renouvellement dans le panier HikaShop ; cela passe via un controlleur d'HikaSerial.

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 235
  • Thank you received: 4
9 months 1 week ago #296778

Bonjour,

Merci pour l'explication du fonctionnement.
Toujours pas de trace de l'IPN côté Hika.
Voici les infos du log paypal pour le paiement d'hier (cf. copie d'écran).
L'url de notification : www.YYYY.fr/index.php?option=com_hikasho...t&lang=fr&Itemid=669
Le contenu du message :

mc_gross=0.10&invoice=693&protection_eligibility=Eligible&address_status=confirmed&payer_id=EWHzzzzzzz8PU&address_street=fghdfg&payment_date=03:47:26 Aug 14, 2018 PDT&payment_status=Completed&charset=windows-1252&address_zip=dfg&first_name=Laurent&mc_fee=0.10&address_country_code=FR&address_name=Laurentéèçùü Colzzzzzzzz - APCHEA&notify_version=3.9&subscr_id=I-R26zzzzzzzzG&payer_status=verified&business=xxxxxx@yyyy.fr&address_country=France&address_city=dfg&verify_sign=AWVhczzzzzzzzQ1AwU6hfFHlY0-ve.-pHrE-DuCGcml&payer_email=cozzzzzzz.laurent@apchea.com&txn_id=4E78zzzzzz7741Y&payment_type=instant&last_name=Cozzzzzzzz&address_state=&receiver_email=xxxxx@yyyy.fr&payment_fee=&receiver_id=7UQBzzzzzzzWA&txn_type=subscr_payment&item_name=Prix total&mc_currency=EUR&residence_country=FR&transaction_subject=Prix total&payment_gross=&ipn_track_id=d4136zzzzzz8

Le fichier log côté hika contient :
Array
(
    [scheme] => https
    [host] => www.paypal.com
    [path] => /cgi-bin/webscr
    [query] => 
    [port] => 443
    [host_socket] => ssl://www.paypal.com
)


VERIFIED

PayPal transaction id: 4E7zzzzzzzzz41Y

Le numéro de transaction paypal (dernière ligne ci-dessous) est bien le même que celui du log papal. Ils semblent communiquer mais rien ne se passe côté Hika. Tout est normal côté Paypal.

Les paramètres de la souscription indique que l'on peut renouveler 1 jour après la fin. De fait, hier le cron l'a fait passé de "active" à "expired" et aujourd'hui elle est passée à "closed". Donc, hier, au moment où l'IPN de paypal s'est déclenchée, le statut de la souscription était "expired".

Quels détails sur le produit vous faut-il ? Je vais essayer de tracer les raisons du non renouvellement....

Pour info, voici la réponse du support technique de paypal :
Les deux lignes ne correspondent pas à des évènement identique. Pour chaque recurring payment créé, 2 notifications seront envoyées, un pour dire qu'un paiement a été effectué et un pour dire qu'un profil de paiement récurrent à été créé.
 
Ce ne sont pas ici vos transactions qui sont "Désactivé" mais l'option IPN qui a été désactivé automatiquement par Paypal dû à un trop grand nombre de notification en échec. Je m'explique :
 
Voici comment fonctionne le système de notification IPN :
 
1 / PayPal envoie une notification IPN à votre boutique.
2 / Votre serveur répond à PayPal une réponse HTTP 200 vide.
3 / Votre boutique retourne le message complet de l'IPN précédé de "cmd=_notify-validate", on appelle cette étape le Post back.
4 / PayPal répond VERIFIED ou INVALID.
 
Voici les logs IPN que j'ai sur les dernières transactions :
Date Message ID Transaction ID Statut
Aug 14, 2018 04:18:57 PDT  18H934zzzzzzzzzzzz37741Y Sent
Aug 13, 2018 01:43:06 PDT  68Azzzzzzzzzzzzzzz613L Sent
Aug 13, 2018 01:43:04 PDT  9PU5zzzzzzzzzzzzzzzzzzzzz37933 Sent
Aug 10, 2018 07:40:50 PDT  7C63zzzzzzzzzzzzz64S Disabled
Aug 10, 2018 04:29:57 PDT  87Fzzzzzzzzzzz0961P Disabled
Aug 10, 2018 03:11:16 PDT  478zzzzzzzzzzz851C Disabled
Aug 10, 2018 00:23:13 PDT  97Dzzzzzzzzzzzzz939 Disabled
Aug 10, 2018 00:23:05 PDT  0Wzzzzzzzzzzzzzz1S Disabled
 
On constate ici que les notifications sont bien présentes mais sont désactivées ("disabled") sur votre compte PayPal.
Cela peut arriver si PayPal rencontre un trop grand nombre d'erreur lors de l'envoi des notification IPNs.
Une notification est considérée en erreur si votre script ne répond pas une réponse HTTP 200 lors de la réception de la notification
 
Je vous invite donc à effectuer les manipulations suivante :
- Manipulation 1 : Réactivation des notification IPN
Pour réactiver les notification pour établir un diagnostic de ce qui ne fonctionne pas sur votre script, je vous invite à activer les IPN vi a la manipulation suivante :
1 / Connectez-vous sur http://www.paypal.com.
2 / Cliquez sur le lien suivant : https://www.paypal.com/fr/cgi-bin/webscr?cmd=_profile-ipn-notify
3 / Cliquez sur "Choisir les paramètres IPN"
4 / Choisissez l'option "Recevoir les messages IPN (activé)".
5 / Enregistrez vos modifications.
 
Remarque : si vous utilisez un gestionnaire de Panier, un Framework/ CMS et que vous ne savez pas quoi mettre dans le champs URL du script IPN, il est probable que cette URL soit envoyée automatiquement par votre boutique.
 Entrez donc l'url de votre boutique dans ce champs qui sera de toute façon écrasé par les informations envoyées par votre boutique.
 
- Manipulation 1 / Enquêtez sur les origine de ces refus IPN :
De plus, je vous invite à enquêter sur vos logs serveurs pour voir si il n'y a pas de trace d'éventuelle erreurs sur votre script IPN pouvant expliquer que PayPal n'ai pas reçu une réponse HTTP 200 lors de l'envoi de ces notifications.
 
Je reste à votre disposition pour tout complément d'informations, il vous suffit de répondre à cet email.
 
Cordialement,

Dans l'état actuel des choses, je pense que le soucis est du côté "hika".

Attachments:
Last edit: 9 months 1 week ago by laurent.

Please Log in or Create an account to join the conversation.

  • Posts: 235
  • Thank you received: 4
9 months 1 week ago #296788

Entre temps, j'ai rajouté des traces et la notification du jour est arrivée. J'ai plein d'infos dans le fichier log.

Je pense que le problème vient de cette section de la fonction onPaymentNotification du plugin paypal_recurring :

		$order_payment_params = null;
		if($vars['txn_type'] == 'subscr_payment') {
			$order_payment_params = $dbOrder->order_payment_params;
			if(empty($order_payment_params))
				$order_payment_params = new stdClass();
			echo "apchea : order_payment_params\r\n". print_r($order_payment_params, true) . "\r\n\r\n";
			if(!empty($order_payment_params->txn_id)) {
				$original_order_id = $order_id;

				$orderClass = hikashop_get('class.order');
				$order_id = $orderClass->createRecurringSuborder($original_order_id);

				if(empty($order_id)) {
					$email = new stdClass();
					$email->subject = JText::sprintf('PAYMENT_NOTIFICATION_FOR_ORDER','Paypal',$vars['payment_status'],$dbOrder->order_number);
					$email->body = str_replace('<br/>',"\r\n",JText::sprintf('PAYMENT_NOTIFICATION_STATUS','Paypal Recurring',$vars['payment_status']))."\r\n".
						'Recurring failed for transaction '.@$vars['txn_id']."\r\n".$order_text;
					$action = false;
					$this->modifyOrder($action, null, null, $email);
					return false;
				}

				$dbOrder = $orderClass->get($order_id);
				$order_payment_params = $dbOrder->order_payment_params;
				if(empty($order_payment_params))
					$order_payment_params = new stdClass();
				unset($order_payment_params->txn_id);
			}

			$order_payment_params->txn_id = @$vars['txn_id'];
		}

Voici la fin du fichier log avec la trace ajoutée :
VERIFIED

PayPal transaction id: 4B92zzzzzzzzzzz003

apchea : order_payment_params
stdClass Object
(
    [subscr_id] => I-R26zzzzzz4SG
)


apchea : dborder_status : confirmed et order_status : confirmed

la variable "$order_payment_params->txn_id" n'est pas positionnée. Je pense qu'on ne passe donc jamais dans la partie qui contient le $orderClass->createRecurringSuborder.

Comme ensuite tout est normal (statut "completed", prix identiques et email du marchand valides) et que les deux statuts de la ligne 550 (environ) sont identiques (confirmed), on sort tranquillement du script sans rien faire.

Reste à savoir pourquoi le txn_id n'est pas stocké lors de la première commande réussie ?....

Last edit: 9 months 1 week ago by laurent.
The following user(s) said Thank You: Jerome

Please Log in or Create an account to join the conversation.

  • Posts: 23435
  • Thank you received: 3643
  • MODERATOR
9 months 1 week ago #296803

Bonjour,

Merci pour votre retour détaillé et vos tests.
La variable txn_id est normalement mise à jour la première fois que "subcr_payment" est appelé.
Après il est possible de se baser sur "subscr_id" et non "txn_id" sachant que "subscr_id" est ajouté lors de l'appel IPN "subscr_signup"

Maintenant le soucis est qu'il n'y a pas de garanti que "subscr_signup" soit appelé avant "subcr_payment" et logiquement il doit y avoir un "subcr_payment" pour la commande de base. D'ou le fait que je me basais sur txn_id et le premier appel de "subcr_payment".

En tout cas pour changer cela, il faut remplacer

if(!empty($order_payment_params->txn_id)) {
En
if(!empty($order_payment_params->subscr_id)) {

Je vais continuer mes investigations pour trouver une documentation claire et précise sur ces appel IPN et leur ordre car j'obtiens avec vos données des incohérences par rapport à la documentation que j'ai lu et ce qui était en place dans le premier plugin.

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 235
  • Thank you received: 4
9 months 1 week ago #296878

Bonjour,

J'ai fait la modif. Mais malgré le fait que j'ai modifié les souscriptions "à la main" les tentatives de notifications de Paypal produisent une erreur 500 dans leur log. J'ai vérifié les fichiers php dans un source checker : aucune erreur de syntaxe signalée.

Aujourd'hui, j'ai donc décidé :
1/ de faire une nouvelle commande et d'attendre demain sans rien faire d'autre pour voir si le renouvellement donne des infos.
2/ d'annuler mon abonnement précédent dans paypal pour qu'il n'envoie plus de notif.

La nouvelle commande s'est bien passée. Tout est nominal. Le log Paypal est "ok" (ci-joint) et le log Hika aussi.
Quand on regarde le log paypal, on voit en bas la 14° tentative d'IPN sur le renouvellement précédent (en echec 500 donc), suivi des deux IPN rapprochées correspondant à ma nouvelle commande. Et, enfin, l'IPN d'annulation de mon abonnement précédent.

dans les urls, on a successivement :
txn_type=subscr_payment
txn_type=subscr_signup

txn_type=subscr_cancel

Il commence donc par envoyer un IPN "subscr_payment", suivi juste après d'un IPN "subsc_signup".

Il y a aussi un ipn "subscr_cancel". Ceci est-il traité par HikaShop ? L'annulation de l'abonnement dans le tableau de bord Paypal entraîne une notification du site mais cela est-il géré, historisé ou utilisé dans Hika ou bien attend-on simplement que le cron passe pour désactiver la souscription puisqu'elle n'aura pas été renouvelée ?

J'attends la tentative de renouvellement pour faire un retour plus complet. Pour être sûr que l'IPN de paypal arrive avant que le cron passe la souscription de "active" à "expired", j'ai modifié l'heure de fin à 23:30. Si cela fonctionne, je referai un essai en "expired".

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 235
  • Thank you received: 4
9 months 1 week ago #296879

je viens de réaliser qu'on est en "checkout legacy". Je ne sais pas pourquoi mais cela peut-il avoir une influence ? (cf. capture)

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 23435
  • Thank you received: 3643
  • MODERATOR
9 months 1 week ago #296883

Bonjour,

Le "checkout legacy" ne devrait pas poser de soucis particulier pour le fonctionnement de Paypal recurring ; mais bien évidement nous conseillons d'utiliser le nouveau système de passage en caisse.

Puisque vous avez bien un "subscr_payment" avant un "subscr_signup", le code d'origine du le plugin (que je vous ai fait modifier) devais bien être fonctionnel. Après nous pouvons toujours voir pour gérer les deux cas.. Mais j'avoue ne pas être fan de "subcr_signup" pour les retours utilisateurs que j'ai pu lire.

subscr_cancel n'as pas besoin d'être géré spécifiquement puisqu'il est la pour annuler la souscription... Qui sera automatiquement expirée dans HikaSubscription de toute façon. Le système accepte la notification mais n'en fait rien.

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 235
  • Thank you received: 4
9 months 1 week ago #296901

Ok, merci pour le retour.

J'ai donc désactivé le legacy checkout.

D'après la chronologie enregistrée dans le log, subscr_payment arrive AVANT subscr_signup. Mais d'un autre côté le log debug Hika, n'est pas cohérent. On a l'impression que les deux IPN sont "mélangées".

De fait, elles se suivent de très près. Et si on en croit les informations paypal, c'est subscr_signup qui est envoyé avant subscr_payment.

Les message indiquent :

txn_type=subscr_signup&subscr_id=I-24UsssssssRK&last_name=Cozzzzzzzzz&residence_country=FR&mc_currency=EUR&item_name=Prix total&business=xxxxx@xxxx.fr&recurring=1&address_street=fghdfg&verify_sign=Aqu12i-pdZE7O2paq1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxNdNCm&payer_status=verified&payer_email=coxxxxxxxxx.laurent@apchea.com&address_status=unconfirmed&first_name=Laurent&receiver_email=xxxxx@yyyy.fr&address_country_code=FR&payer_id=EWxxxxxxxU&invoice=705&address_city=dfg&reattempt=1&address_state=&subscr_date=02:38:20 Aug 18, 2018 PDT&address_zip=dfg&charset=windows-1252&notify_version=3.9&period3=1 D&address_country=France&mc_amount3=0.10&address_name=Laurentéèçùü Coxxxxxxxxx - APCHEA&ipn_track_id=860xxxxxxxx9d

et, 5 secondes plus tard ?....
mc_gross=0.10&invoice=705&protection_eligibility=Eligible&address_status=unconfirmed&payer_id=EWxxxxxxxxxxxxxU&address_street=fghdfg&payment_date=02:38:25 Aug 18, 2018 PDT&payment_status=Completed&charset=windows-1252&address_zip=dfg&first_name=Laurent&mc_fee=0.10&address_country_code=FR&address_name=Laurentéèçùü Collongues - APCHEA&notify_version=3.9&subscr_id=I-24U4EBB4A7RK&payer_status=verified&business=xxxxx@yyyy.fr&address_country=France&address_city=dfg&verify_sign=AO0ppxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxeW6&payer_email=coxxxxxxxxxxxx.xxxxxxxxxxlaurent@apchea.com&txn_id=91xxxxxxxxxxxx4D&payment_type=instant&last_name=Coxxxxxxxxxxxx&address_state=&receiver_email=xxxxx@zzzz.fr&payment_fee=&receiver_id=7UxxxxxxxxxxxxxxxxxxxxxxWA&txn_type=subscr_payment&item_name=Prix total&mc_currency=EUR&residence_country=FR&transaction_subject=Prix total&payment_gross=&ipn_track_id=86xxxxxxxxx9d

serait-il possible que les deux IPN arrivent "en même temps" sur le serveur et induisent ce comportement bizarre ?

Par ailleurs, Paypal a fait son IPN pour le renouvellement de la souscription d'hier. Mais cela ne passe pas du tout. Code 500 en retour et aucun message dans le log debug Hika ni aucune action sur la souscription ou la commande. Pourtant j'ai modifié le code pour inscrire un message dans le log dès la première ligne de la fonction onPaymentNotification du paypal_recurring.php :
	public function onPaymentNotification(&$statuses) {
		echo "apchea : start onPaymentNotification\r\n\r\n";
		$vars = array();
		$data = array();
		$filter = JFilterInput::getInstance();

Pour moi, quelque chose "coince" avant d'invoquer le plugin dans ce cas.

L'url est "normale" (la même que pour l'achat initial qui s'était bien passé) : www.yyyy.fr/index.php?option=com_hikasho...t&lang=fr&Itemid=669

et le message envoyé pour ce renouvellement :
mc_gross=0.10&invoice=705&protection_eligibility=Eligible&address_status=confirmed&payer_id=EWxxxxxxxPU&address_street=fghdfg&payment_date=07:26:15 Aug 19, 2018 PDT&payment_status=Completed&charset=windows-1252&address_zip=dfg&first_name=Laurent&mc_fee=0.10&address_country_code=FR&address_name=Laurentéèçùü Coxxxxxxxxxx - APCHEA&notify_version=3.9&subscr_id=I-24xxxxxxxxK&payer_status=verified&business=xxxxx@yyyy.fr&address_country=France&address_city=dfg&verify_sign=A2L5KxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxgD&payer_email=coxxxxxxxxx.laurent@apchea.com&txn_id=7Vxxxxxxxxxxxx4W&payment_type=instant&last_name=Coxxxxxxx&address_state=&receiver_email=xxxxx@yyyy.fr&payment_fee=&receiver_id=7UxxxxxxxxxxWA&txn_type=subscr_payment&item_name=Prix total&mc_currency=EUR&residence_country=FR&transaction_subject=Prix total&payment_gross=&ipn_track_id=86xxxxxxxxxxxxxxd

La souscription est toujours active (ipn initiale et 9 tentatives à cet instant....)

Dans le log du serveur les deux lignes. L'une (la commande initiale) avec un code retour à 200 et l'autre (le renouvellement) avec un code retour à 500 (sur l'essai d'hier) :
173.xxx.xxx.1 www.yyyy.fr - [18/Aug/2018:11:37:29 +0200] "POST /index.php?option=com_hikashop&ctrl=checkout&task=notify&notif_payment=paypal_recurring&tmpl=component&lang=fr&Itemid=669 HTTP/1.1" 500 870 "-" "PayPal IPN ( https://www.paypal.com/ipn )"

173.xxx.xxx.1 www.yyyy.fr - [18/Aug/2018:11:38:31 +0200] "POST /index.php?option=com_hikashop&ctrl=checkout&task=notify&notif_payment=paypal_recurring&tmpl=component&lang=fr&Itemid=669 HTTP/1.1" 200 - "-" "PayPal IPN ( https://www.paypal.com/ipn )"

Là je sèche.....

Last edit: 9 months 6 days ago by Jerome. Reason: remove color tags in code tags

Please Log in or Create an account to join the conversation.

Moderators: Obsidev
Time to create page: 0.104 seconds
Powered by Kunena Forum