Difficultés avec le paiement récurrent

Jerome
Away
HikaShop core developer

Posts: 26000
Thank you received: 4004
MODERATOR

5 years 8 months ago #296908

Bonjour,

Si vous avez un retour "500" c'est lié à une erreur fatale PHP.
Le mieux serait de regarder dans votre fichier de log PHP afin d'en savoir un peu plus sur cette erreur.

Dans le cas ou vous souhaitez avoir du log, il est préférable de passer via " $this->writeToLog(...) " plutôt que par un "echo" ; car s'il y a une erreur et que la notification ne se termine pas, HikaShop n'ira pas récupérer ce qui a été affiché pour l'envoyer dans le log.

Pour ce qui est de "subscr_payment" et "subscr_signup" ; peut importe.. Cela n'a aucune importance (mais vraiment aucune).
Vous avez confirmé ce que je disais et également l'algorithm d'origine du plugin : Il y a bien un "subscr_payment" qui est fait pour la commande ; le premier appel doit donc être sauvegardé et ne dois pas généré de nouvelle commande.

Veuillez également noter que vos notifications ne sont pas en UTF8
CF : www.hikashop.com/support/documentation/1...or.html#notification

Please check that your PayPal merchant account is configured to send UTF8 payment notifications as explained here: simple-membership-plugin.com/setting-utf...paypal-ipn-messages/

Sachant que l'un des appel va faire une modification de la commande, entraînant pas mal de "processing" et l'envoie de notification ; il est normal que l'un des appel puisse prendre nettement plus de temps que l'autre et donc apparaître après même si l'appel a été fait "avant".

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.

Last edit: 5 years 7 months ago by Jerome.

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

laurent
Topic Author
Offline

Posts: 246
Thank you received: 5

5 years 7 months ago #297047

Bonjour,

Suite à votre dernier post, j'ai modifié la config paypal pour que les IPN envoient de l'UTF-8. Il semble que maintenant, le script paypal_recurring soit systématiquement appelé. Il n'y a plus l'erreur 500 avant l'appel de la fonction onPaymentNotification.

Le log contient maintenant la trace de l'appel à cette fonction à chaque tentative de Paypal d'envoyer son IPN.

Il semble que le mélange entre les "echo" et les $this->writeToLog produisent des "trous" dans le log. Notamment le code d'origine suivant :

		if($this->payment_params->debug)
//			echo print_r($vars, true) . "\r\n\r\n";
			$this->writeToLog("apchea : vars :".print_r($vars, true)."\r\n\r\n");

Je n'avais plus l'echo des vars envoyées par l'IPN dans le log.... J'ai donc mis des "writeToLog" partout....

Ceci dit, j'avais toujours une erreur 500. J'ai donc suspecté la fonction createRecurringSuborder. De fait, il y avait un double ";" qui génère une erreur php autour de la ligne 2014 du script original :

		$order->order_parent_id = (int)$order_id;
//		$order->order_status = $config->get('order_created_status', 'created');;
		$order->order_status = $config->get('order_created_status', 'created');

Mais bon, toujours erreur 500. Visiblement le code est buggué.... Ci-joint le log des dernières tentatives de Paypal et la copie d'écran du log côté paypal correspondant à la toute fin du fichier

Attachments:

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

Jerome
Away
HikaShop core developer

Posts: 26000
Thank you received: 4004
MODERATOR

5 years 7 months ago #297061

Bonjour,

Je crains ne pas pouvoir vous dire plus que mon dernier message :

Si vous avez un retour "500" c'est lié à une erreur fatale PHP.
Le mieux serait de regarder dans votre fichier de log PHP afin d'en savoir un peu plus sur cette erreur.

Cordialement,

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

laurent
Topic Author
Offline

Posts: 246
Thank you received: 5

5 years 7 months ago #297160

Bonjour,

Etant sur un serveur mutualisé, OVH, pour l'instant, ne donne pas accès aux logs des erreurs du PHP. Sinon je l'aurais fait depuis longtemps. Je les ai contacté pour y avoir accès. Sans réponse pour l'instant.

La dernière cause d'erreur 500 provenait d'un double ";" dans le code fourni par HikaShop. Je ne vois pas comment le script contenant cette fonction n'a pas pu produire une erreur lors de vos propres tests ?

Ce matin, j'ai envoyé l'url complète de paypal via le navigateur pour voir si j'avais un retour. Il répond :

1054
Erreur: 1054
Unknown column 'order_parent_id' in 'field list'

Sans pour autant que je puisse savoir dans quelle partie de votre code cela se passe.

Je pense que si vous faites des tests sur un produit associé à une souscription payé via ce plugin et un "vrai" compte paypal (pas le sandbox), vous pourrez tout à fait reproduire ce problème et en trouver l'origine.

Il y a manifestement un soucis avec ce code.

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

Jerome
Away
HikaShop core developer

Posts: 26000
Thank you received: 4004
MODERATOR

5 years 7 months ago #297162

Bonjour,

Un double ";" ne génère pas d'erreur fatale.

Pour ce qui est de la colonne "order_parent_id" ; il s'agit bien de la source de votre soucis et c'est une chose que je n'ai pas pu voir dans mes douzaines de tests puisqu'il s'agit d'une colonne qui est ajoutée par HikaMarket et tous mes sites de tests ont toutes mes extensions d'installées.
Sachant que la colonne n'est pas utilisée pour le moment ; vous pouvez simplement commenter la ligne.
Je vais voir pour commenter la ligne également dans les packages en cours et voir si nous intégrons cette colonne dans HikaShop ou non.

Cordialement,

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

laurent
Topic Author
Offline

Posts: 246
Thank you received: 5

5 years 7 months ago #297216

Bonjour,

D'accord pour modifier la ligne mais dans quel fichier ?

Merci

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

Jerome
Away
HikaShop core developer

Posts: 26000
Thank you received: 4004
MODERATOR

5 years 7 months ago #297217

Bonjour,

Nicolas m'a indiqué qu'il avait mit les nouveaux package en ligne. Donc vous pouvez re-télécharger HikaShop si jamais.
Au niveau du fichier, il s'agit de la class order, dans la fonction "createRecurringSuborder" que vous avez mentionné précédemment :

$order->order_parent_id = (int)$order_id;

Cordialement,

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

laurent
Topic Author
Offline

Posts: 246
Thank you received: 5

5 years 7 months ago #297227

Bonjour,

Je vais faire une boucle de test complète avant de crier victoire mais, là, en envoyant l'url paypal complète depuis le navigateur, la commande a été créée et la souscription mise à jour... ouf !
Il reste encore deux-trois trucs à corriger mais on s'approche du but.
Je vais attendre de valider tout cela avant de mettre le package à jour car le surplus de traces que j'ai ajoutées pourrait être encore utile.

Merci,

Laurent

Last edit: 5 years 7 months ago by laurent.

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

laurent
Topic Author
Offline

Posts: 246
Thank you received: 5

5 years 7 months ago #297231

Première étape : création de la commande initiale pour une souscription d'un jour.
La facture génère un "notice" (cf. copie d'écran). Cela vient du fait que j'ai remonté fortement les niveaux d'erreur affichés. En mode "prod" normal cela n'apparaîtrait probablement pas. Pour autant c'est peut-être quelque chose à corriger ?
Cela semble venir de la dernière ligne de ce bloc :

		$paymentClass = hikashop_get('class.payment');
		$payment = $paymentClass->get($order->order_payment_id);
		echo $payment->payment_params->information;

Attachments:

Last edit: 5 years 7 months ago by laurent.

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

Jerome
Away
HikaShop core developer

Posts: 26000
Thank you received: 4004
MODERATOR

5 years 7 months ago #297272

Bonjour,

Votre soucis semble lié à un plugin (attachinvoice) et il est déjà corrigé en 2016 par Nicolas.

Cordialement,

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

laurent
Topic Author
Offline

Posts: 246
Thank you received: 5

5 years 7 months ago #297317

Bonjour,

Et bien voilà. Tout se passe bien. Il a renouvelé tout seul la souscription. Ouf....
Du coup, faut-il que je fasse la mise à jour ? Actuellement, je fonctionne avec :

			$this->writeToLog("apchea : order_payment_params\r\n". print_r($order_payment_params, true) . "\r\n\r\n");
//			if(!empty($order_payment_params->txn_id)) {
			if(!empty($order_payment_params->subscr_id) || !empty($order_payment_params->txn_id)) {

Dans onPaymentNotification. Et le fichier log indique bien que l'objet stocké ne contient que subscr_id.

Et avec celles-ci dans onAfterOrderConfirm :

		$recurring_unit = false;
//		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;
		}

Pour l'attach-invoice vous avez raison. Les fichiers datent de 2016. On a jamais dû mettre cela à jour (il n'apparaît pas dans les joomla updates). Je suppose qu'il faut racheter le plugin et le ré-installer ?

Le bouton renouveler votre souscription dans l'interface utilisateur refonctionne à nouveau maintenant.
Autant ce bouton est pertinent pour les moyens de paiement conventionnels, autant il me semble inapproprié dans le cas du paypal_recurring. En effet, d'après mes essais, si on clique dessus, il met au panier le produit initial (create and renew) et déclenche un nouvel abonnement auprès de paypal. Pour une même souscription on se retrouve donc avec deux "flux" de renouvellement (et deux abonnements déclarés dans Paypal). Ce n'est pas dramatique car cela ajoute "un cran" de renouvellement à chaque fois. Le client n'est pas lésé. Mais il va voir l'échéance de fin d'abonnement repoussée d'un mois supplémentaire tous les mois (dans le cas d'un abonnement d'un mois bien sûr). Car Paypal va déclencher deux paiements tous les mois pour cette souscription.
On pourrait bien sûr ne pas autoriser le renouvellement en jouant sur les périodes avant/après ou il est possible d'autoriser le renouvellement manuel mais ce paramètrage est global et s'applique donc à toutes les souscriptions. Idéalement, il faudrait pouvoir l'ajuster pour chaque plan.
A moins, bien sûr que vous ayez une autre solution pour éviter que l'utilisateur ne déclenche ce renouvellement inapproprié ?

Merci.

Je continue mes tests.

Laurent

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

Jerome
Away
HikaShop core developer

Posts: 26000
Thank you received: 4004
MODERATOR

5 years 7 months ago #297321

Bonjour,

1 - Il n'est pas nécessaire de réinstaller pour l'instant ; la prochaine mise à jour contiendra diverses modifications dont une pour gérer un l'accumulation des order payment params ; corrigeant votre soucis de perte de "txn_id" lors de l'IPN "subscr_signup".

2 - Vous pouvez simplement appliquer un petit patch dans votre plugin afin de masquer la notice, mettre à jour juste pour cela me semble inutile... Mais je ne connais pas l'évolution de ce plugin.
Pour plus de détails le mieux est de poser la question à l'équipe de support d'HikaShop.

3 - En effet, il n'y a pas encore l'information du type/état de "renouvellement" (d'un point de vu plugin) pour les souscriptions.
Cela va venir avec la gestion d'un nouveau type de renouvellement et va également permettre à l'utilisateur de désactiver le renouvellement automatique (en faisant donc appel aux fonctionnalités du plugin correspondant, dans le cas où cette fonction existe)
Il s'agit d'évolutions et développements sur lesquels nous travaillons.

Cordialement,

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

laurent
Topic Author
Offline

Posts: 246
Thank you received: 5

5 years 7 months ago #297418

Bonjour,

Tout se passe bien et les renouvellements se font normalement.
Pour l'instant je conserve le plugin en l'état et on verra lors de la prochaine livraison d'Hika.
Idem pour AttachInvoice, je vais faire en sorte que le warning n'apparaisse plus pour l'instant.

Pour le bouton "renouveler" j'attendrai vos évolutions et on gèrera au cas par cas. Nous avons des abonnements (annuels) pour lesquels nous devons laisser le choix au client de renouveler ou pas (bouton en front end et paiement CB) et d'autres (mensuels) pour lesquels le client doit choisir paypal_recurring et la forme de prélèvement auto qui va avec.

L'informations relative à la commande n'est pas transmise à PayPal malgré le bouton coché "send details of the order" (cf. Capture).
On transmet bien le nom et le code du produit dans les champs Item_name_1 et Item_number_1 mais le terme "Prix total" dans le champ "item_name". Ce dernier est le seul repris dans le recap des abonnements vu par le dashboard de Paypal (cf. Autre capture). Ce n'est vraiment pas "causant". Voici ce qu'indique le log :

Laurent

Attachments:

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

Jerome
Away
HikaShop core developer

Posts: 26000
Thank you received: 4004
MODERATOR

5 years 7 months ago #297433

Bonjour,

Je crains de ne pas pouvoir dire grand chose sur le "send order details" sachant que le plugin utilise exactement le même code que le plugin Paypal d'HikaShop.

	if(empty($this->payment_params->details)) {
		$vars['amount_1'] = number_format($order->cart->full_total->prices[0]->price_value_with_tax, 2, '.', '');
		$vars['item_name_1'] = JText::_('CART_PRODUCT_TOTAL_PRICE');
	} else {
		...

Cordialement,

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

laurent
Topic Author
Offline

Posts: 246
Thank you received: 5

5 years 7 months ago #297458

Bonjour,

En fait, je ne crois pas. Les informations fournies à Paypal via l'ancien paypalrecurring sont plus claires (cf. capture). De fait, dans
l'ancien plugin on a ceci :

		// Product information (if 1 product > name of the product // else echo "total price")
		if($order->cart->order_full_quantity == 1){
			$vars["item_name"]=strip_tags($order->cart->products[0]->order_product_name);
		}else{
			$vars["item_name"]=JText::_('CART_PRODUCT_TOTAL_PRICE');
		}

Par ailleurs, on peut remarquer que dans paypal_recurring, vous initialisez la valeur 'cmd' du tableau des variables avec "_cart" dans onAfterOrderConfirm. Mais un peu plus bas cette même valeur est mise à "_xclick-subscriptions" ce qui semble logique puisque c'est ce qu'on veut faire.

Mais la construction des éléments de la commande les champs de type item_name_x / item_number_x semblent réservés à l'affichage du récap du panier (cmd=_cart) selon ces pages : developer.paypal.com/docs/classic/paypal...ng-payment-variables . J'ai l'impression qu'il faut faire deux requêtes à paypal, l'une pour le _cart (infos du panier d'achat) et l'autre pour le "_xclick-subscriptions" (simulation du bouton "souscrire un abonnement").

Cela implique probablement de modifier profondément le script. En attendant, on pourrait rétablir le mécanisme de l'ancien plugin (ci-dessus) puisque le plus souvent dans le panier de l'acheteur il n'y a qu'un produit dans le cas d'un abonnement.

D'autre part, je souhaiterais rétablir la fonctionnalité qui permet de limiter la portée d'un abonnement. En effet, la seule façon d'arrêter un abonnement pour le client c'est de le faire via paypal. Avec paypal_recurring, il n'existe pas de possibilité depuis HikaShop (back ou front) de stopper un abonnement. Le fait de forcer la souscription à inactive ne suffit pas.

La variable correspondante de Paypal existe dans l'ancien plugin :

		// Number of recurring times, if period = 1 month and srt = 4, so there will be 4 payments
		if($method->payment_params->recurring_times != '0'){
			$vars["srt"]= (int)$method->payment_params->recurring_times;
		}

Bien sûr, idéalement, cela devrait être lié au plan mais ce serait déjà pas mal de pouvoir le spécifier dans les paramètres du plugin de paiement.

Cela semble possible sans "chambouler" toute la logique, non ?

Merci,

Laurent

Attachments:

Last edit: 5 years 7 months ago by laurent.

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

laurent
Topic Author
Offline

Posts: 246
Thank you received: 5

5 years 7 months ago #297479

Bonjour,

Paypal envoie des IPN qui sont "captés" par le plugin hikashop et provoque des "notices". Notamment, les subscr_eot envoyées lorsque l'utilisateur annule son abonnement depuis la console Paypal. En toute logique elle devrait être traitée par paypal_recurring (au moins pour garder une trace dans le log de la souscription ou de la commande ?). Voici ce qu'indique le fichier debug :

<h3>09.01.18 14:21:43 - paypal_recurring</h3>
apchea : start onPaymentNotification

<h3>09.01.18 14:21:43 - paypal_recurring</h3>
apchea : vars :Array
(
    [option] => com_hikashop
    [ctrl] => checkout
    [task] => notify
    [notif_payment] => paypal_recurring
    [tmpl] => component
    [lang] => fr
    [Itemid] => 669
    [txn_type] => subscr_eot
    [subscr_id] => I-A7xxxxxxxxHN
    [last_name] => Cccccccccc
    [residence_country] => FR
    [item_name] => Prix total
    [mc_currency] => EUR
    [business] => xxxxxx@yyyy.fr
    [verify_sign] => AcU-fz2m7Mh8VC-wctrVXL4qyYblAntILRUcPSdkKWu5bNlexy0F0aSH
    [payer_status] => verified
    [payer_email] => ccccccccc.laurent@apchea.com
    [first_name] => Laurent
    [receiver_email] => xxxxx@yyyy.fr
    [payer_id] => EWxxxxxxxxxxPU
    [invoice] => 712
    [charset] => UTF-8
    [notify_version] => 3.9
    [ipn_track_id] => 86e52ebb5d5de
)

<h3>09.01.18 14:21:43 - paypal_recurring</h3>
apchea : url : Array
(
    [scheme] => https
    [host] => www.paypal.com
    [path] => /cgi-bin/webscr
    [query] => 
    [port] => 443
    [host_socket] => ssl://www.paypal.com
)

<h3>09.01.18 14:21:45 - paypal_recurring</h3>
apchea : response : VERIFIED

<h3>09.01.18 14:21:45 - paypal_recurring</h3>
apchea : PayPal transaction id: 

<h3>09.01.18 14:21:45 - paypal_recurring</h3>
apchea : payment 

<b>Notice</b>:  Undefined index: payment_status in <b>/home/lactfrwpxp/www/plugins/hikashoppayment/paypal_recurring/paypal_recurring.php</b> on line <b>494</b>
<b>Notice</b>:  Undefined index: payment_status in <b>/home/lactfrwpxp/www/plugins/hikashoppayment/paypal_recurring/paypal_recurring.php</b> on line <b>495</b>
<b>Notice</b>:  Undefined index: payment_status in <b>/home/lactfrwpxp/www/plugins/hikashoppayment/paypal_recurring/paypal_recurring.php</b> on line <b>498</b>
<b>Notice</b>:  Undefined index: payment_status in <b>/home/lactfrwpxp/www/plugins/hikashoppayment/paypal_recurring/paypal_recurring.php</b> on line <b>499</b>
<b>Notice</b>:  Undefined index: payment_status in <b>/home/lactfrwpxp/www/plugins/hikashoppayment/paypal_recurring/paypal_recurring.php</b> on line <b>505</b>

J'ai ajouté une "protection" autour de la ligne 494 (à peu près) :

		if (array_key_exists('payment_status',$vars)) {
			$completed = preg_match('#Completed#i', $vars['payment_status']);
			$pending = preg_match('#Pending#i', $vars['payment_status']);
		} else {
			$vars['payment_status'] = "not set";
		}
		if(!$completed && !$pending) {
			$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',$vars['payment_status'])).' '.JText::_('STATUS_NOT_CHANGED')."\r\n\r\n".JText::sprintf('CHECK_DOCUMENTATION',HIKASHOP_HELPURL.'payment-paypal-error#status').$order_text;
			$action = false;
			$this->modifyOrder($action, null, $history, $email);

			if($this->payment_params->debug)
//				echo 'payment ' . $vars['payment_status'] . "\r\n\r\n";
				$this->writeToLog("apchea : payment " . $vars['payment_status'] . "\r\n\r\n");		
			return false;
		}

Pas très important, mais....

Par ailleurs, je pense qu'il y a un risque que le renouvellement soit "loupé" car Paypal envoie ses IPN à n'importe quelle heure. Le cron peut avoir passé la souscription de "active" à "closed" avant que l'IPN ne soit reçue (cf. captures). Je suppose que le paypal_recurring ne repasse pas en "active" une souscription que le cron a positionné "closed" ?
Dans mon cas, j'ai paramétré le plan pour autoriser le renouvellement un jours après l'expiration. Donc, la souscription passe active->expired->active. Ce n'est pas très grave dans notre cas mais cela peut être gênant car le client peut être "désabonné" pendant quelques heures alors qu'il paye.
De plus, Paypal va continuer l'abonnement (et donc faire des paiements) alors que la souscription est définitivement closed ?....

Etant donné que la granularité minimum des abonnements est la journée, je pense que le cron ne devrait changer les statuts qu'une fois minuit passé et non pas exactement x foix 24 heures après le début de la souscription. Cela laisserait le temps à Paypal de procéder au paiement (et accessoirement le client dans le cas d'un renouvellement manuel).

On peut aussi baisser la fréquence du cron. Mais il sert aussi à d'autres tâches je crois ?...

Laurent

Attachments:

Last edit: 5 years 7 months ago by laurent.

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

Jerome
Away
HikaShop core developer

Posts: 26000
Thank you received: 4004
MODERATOR

5 years 7 months ago #297493

Bonjour,

Il n'est aucunement possible de faire plusieurs requête paypal ; une requête = une transaction.
Donc je suis navré mais ce dont vous parlez n'est pas possible.

Soit, l'ancien plugin avait un code spécifique pour une effectuer une action très spécifique pour un cas d'utilisation spécifique également... Mais cela ne gère aucunement la nouvelles possibilités proposées par HikaShop et HikaSubscription.
Le nouveau plugin est flexible et gère des modes différents ; c'est ainsi qu'il a été conçu.
Et non le fonctionnement de l'ancien plugin n'est aucunement utilisable pour nos besoins ; pour ce qui est de la modification de la souscription je vous ai déjà répondu dans un précédent message. Le résultat que vous avez est donc ce que je vous ai déjà indiqué auparavant.

Je prends note de votre notice PHP.

Dans mon cas, j'ai paramétré le plan pour autoriser le renouvellement un jours après l'expiration.

Nous avons déjà abordé ce sujet précédemment et c'est ce que je vous avais dit de faire.

Cordialement,

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

laurent
Topic Author
Offline

Posts: 246
Thank you received: 5

5 years 7 months ago #297496

Bonjour,

Je ne comprends pas trop vos réponses. J'ai fait deux posts successifs.

Pour ce qui concerne le fait que l'objet de l'achat n'est pas transmis à Paypal, il y a bien une différence de codage (cf. mon premier post).

Je n'ai jamais parlé de plusieurs transactions. Mais juste du paramètre "srt" de paypal qui était disponible dans l'ancien plugin et qui permet de définir un terme à l'abonnement en spécifiant un nombre max de paiements récurrents. Je l'ai mis en constante dans le plugin et cela fonctionne très bien. Cela permet par exemple de limiter un abonnement par renouvellement mensuel à un an (12 prélèvements). Paypal arrête d'envoyer des IPN et de retirer de l'argent sur le compte du client au bout de 12 prélèvements. Et, côté Hika, la souscription s'éteint naturellement via le cron parcequ'il n'aura pas reçu de 13° IPN de payment....

La solution qui consiste à permettre le renouvellement d'une souscription un jour après la fin de la souscription pour permettre à l'IPN paypal de renouveler malgré le décalage d'heure est un "contournement" pas une solution. Cette approche entraîne deux inconvénients :
1/ le client est potentiellement désabonné pendant plusieurs heures alors qu'il n'a rien fait pour (il ne fait plus partie du groupe autorisé à consulter certains articles)
2/ le client peut être tenté de renouveler via le bouton qui apparaîtra dans son interface ce qui entraîne un double abonnement paypal avec double prélèvement comme je l'ai déjà expliqué.

Cela fait des années que j'utilise HikaShop et l'ai installé sur une bonne vingtaine de sites clients.Globalement cela fonctionne bien et c'est plutôt stable. Mais il me semble normal que les "nouveautés" aient des périodes de rodage. J'essaye de solliciter le support en fournissant le plus d'éléments. Je ne demande pas de développements spécifiques. Je fais juste des suggestions et signale ce qui, selon mes tests, va provoquer des anomalies ou ne fonctionne pas. Cela mériterait peut-être une réponse un peu plus circonstanciée de votre part.

Merci,

Laurent

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

Jerome
Away
HikaShop core developer

Posts: 26000
Thank you received: 4004
MODERATOR

5 years 7 months ago #297498

Bonjour,

1 - Le paramètre "srt" était disponible dans l'ancien plugin car cet ancien plugin n'était pas en relation directe avec un composant de souscription.
Ce n'est pas au plugin de prendre ce genre "d'initiative" dans notre context actuel.

2 - Nous travaillons et réfléchissons à des solutions pour cela.
Une des idées est de pouvoir rajouter un nombre d'heures supplémentaire ; pour ce qui est de pousser la souscription à minuit, cela ne peut pas forcement fonctionner avec la problématique de fuseau horaire. Nous continuons de regarder cette piste et nous proposerons peut-être deux solution au fonction des besoin de l'utilisateur.

Vos remarques sont notées et prise en compte pour l'évolution du composant.
Certains points ont déjà été notés précédemment avec une solution de contournement pour "patienter".

Cordialement,

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

laurent
Topic Author
Offline

Posts: 246
Thank you received: 5

5 years 7 months ago #297580

Bonjour,

Je comprends votre position mais il faut que j'ai une solution. J'ai donc "hacké" paypal_recurring pour qu'il mette autre chose que "Prix Total" dans l'objet des récaps Paypal et pour que l'on puisse définir un nombre de paiements définis et pas seulement "infini".

Je comprends que cela ne correspond pas à votre schéma de dév mais en attendant une solution plus pertinente, cette modification nous permet de faire face exactement à notre problématique (qui n'est probablement pas unique) et d'offrir à nos clients une solution souple et confortable sans que l'on en perde la maîtrise (cf. copies d'écrans).

Voici les (très simples) modifs apportées ci-dessous. En toute logique si on crée deux instances du même plugin avec deux "srt" différents, on devrait avoir ces deux possibilités de paiements étalés (pseudo abonnements) sans "croisement" ?

Ajout d'un champ de config du plugin dans la définition de classe ligne 52 :

		'validation' => array('ENABLE_VALIDATION', 'boolean', 1),
		'debug' => array('DEBUG', 'boolean', 0),
		'recurring_times' => array('RECURRING_TIMES', 'input'),
		'cancel_url' => array('CANCEL_URL', 'input'),

Ajout de la possibilité de prendre en compte "srt" à la fin de onAfterOrderConfirm :

			$vars['src'] = 1;
// Added by Apchea
			if (!empty($this->payment_params->recurring_times)) {
				$srt = (int)$this->payment_params->recurring_times;
				if ($srt > 1 && $srt <= 52) $vars['srt'] = $srt;
			}
// ______ end Apchea ______	
			$vars['sra'] = !empty($this->payment_params->reattempt) ? 1 : 0;

Ajout de la modification pour mettre en objet le produit si le panier n'en contient qu'un :

// modif APCHEA			
			if(!array_key_exists('item_name_2', $vars)) {
				$vars['item_name'] = $vars['item_name_1'];
				$vars['item_number'] = $vars['item_number_1'];				
			} else {
				$vars['item_name'] = JText::_('CART_PRODUCT_TOTAL_PRICE');
			}
// end modif APCHEA

Tout ça est "rustique" mais suffisant pour l'instant.

Merci pour votre aide. Je ferai un nouveau post si nécessaire. On peut clôturer celui-ci.

Cordialement,

Laurent

Attachments:

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

Moderators: Obsidev

Time to create page: 0.105 seconds