Suite mise à jour 1.7.5.2 -> 1.7.6.0 les retours bancaire ne se font pas !

flyman30 · July 22, 2019

Bonjour, suite à la mise à jour 1.7.5.2 -> 1.7.6.0 le module bancaire E-transaction plantait, en corrigeant la table ps_currency le module transmet les données à la banque, hélas la banque ne retourne pas la réponse "accepté ou non" donc PrestaShop ne mets pas à jour le paiement des commandes et les mails ne partent pas.

J'ai regardé les logs de transaction et voilà ce que ça indique :

Citation

AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Call to a member function get() on null in /var/www/vhosts/pierre-sempe.com/httpdocs/classes/Tools.php:801\nStack trace:\n#0 /var/www/vhosts/pierre-sempe.com/httpdocs/classes/Tools.php(773): ToolsCore::getContextLocale(Object(Context))\n#1 /var/www/vhosts/pierre-sempe.com/httpdocs/classes/PaymentModule.php(421): ToolsCore::displayPrice(9.6, Object(Currency), false)\n#2 /var/www/vhosts/pierre-sempe.com/httpdocs/modules/etransactions/etransactions.php(925): PaymentModuleCore->validateOrder(1190, '2', 17.1, 'E-Transactions', 'Le paiement a \\xC3...', Array, NULL, false, '01e083d45ca21d3...')\n#3 /var/www/vhosts/pierre-sempe.com/httpdocs/modules/etransactions/classes/ETransactionsController.php(241): ETransactions->onMixedIPNSuccess(Object(Cart), Array)\n#4 /var/www/vhosts/pierre-sempe.com/httpdocs/modules/etransactions/index.php(69): ETransactionsController->ipnAction()\n#5 {main}\n thrown in /var/www/vhosts/pierre-sempe.com/httpdocs/classes/Tools.php on line 801\n'

Une idée du problème?

Ça commence à saouler grave ces mises à jour foireuses...

tdf-mep · July 22, 2019

Bonjour,

Nous avons le même problème avec le module cmcicpaiement lors d'un paiement.

Après mise à jour manuel de la table ps_currency ( numeric_iso_code & precision cf : https://github.com/PrestaShop/PrestaShop/issues/14608 ) qui à permis de résoudre une bonne partie des autres problèmes :

Une erreur est levée lors de l'appel à ToolsCore::displayPrice => ToolsCore::getContextLocale(Object(Context))

[Mon Jul 22 11:03:34.953382 2019] [php7:error] [pid 1792] [client XX.XX.XX.XX:37428] PHP Fatal error:  Uncaught Error: Call to a member function get() on null in 
/xxxxxxxxxxxx/public_html/classes/Tools.php:801\nStack trace:\n#0 
/xxxxxxxxxxxx/public_html/classes/Tools.php(773): ToolsCore::getContextLocale(Object(Context))\n#1 
/xxxxxxxxxxxx/public_html/classes/Notification.php(133): ToolsCore::displayPrice(31.35, Object(Currency), false)\n#2 
/xxxxxxxxxxxx/public_html/classes/Notification.php(57): NotificationCore::getLastElementsIdsByType('order', '20821')\n#3 
/xxxxxxxxxxxx/public_html/zzzzzzz/ajax.php(125): NotificationCore->getLastElements()\n#4
 {main}\n  thrown in /xxxxxxxxxxxx/public_html/classes/Tools.php on line 801, referer: https://www.yyyyyyyyyy.com/zzzzzzz/index.php?controller=AdminStats&token=2cf9909b77f74d62ff078e389febe409

[...]

[Mon Jul 22 11:09:31.457138 2019] [php7:error] [pid 10243] [client XX.XX.XX.XX:43994] PHP Fatal error:  Uncaught Error: Call to a member function get() on null in 
/xxxxxxxxxxxx/public_html/classes/Tools.php:801\nStack trace:\n#0 
/xxxxxxxxxxxx/public_html/classes/Tools.php(773): ToolsCore::getContextLocale(Object(Context))\n#1 
/xxxxxxxxxxxx/public_html/classes/PaymentModule.php(421): ToolsCore::displayPrice(4.9, Object(Currency), false)\n#2 
/xxxxxxxxxxxx/public_html/modules/cmcicpaiement/validation.php(123): PaymentModuleCore->validateOrder(123246, '2', '9.60', 'CM-CIC P@iement', 'TPE: 6600893<br...', NULL, 1, true, 'd67985d7118f76f...')\n#3
{main}\n  thrown in /xxxxxxxxxxxx/public_html/classes/Tools.php on line 801

[Mon Jul 22 11:09:33.208743 2019] [php7:error] [pid 10205] [client XX.XX.XX.XX:43996] PHP Fatal error:  Uncaught Error: Call to a member function get() on null in 
/xxxxxxxxxxxx/public_html/classes/Tools.php:801\nStack trace:\n#0 
/xxxxxxxxxxxx/public_html/classes/Tools.php(773): ToolsCore::getContextLocale(Object(Context))\n#1 
/xxxxxxxxxxxx/public_html/classes/order/OrderHistory.php(513): ToolsCore::displayPrice(9.6, Object(Currency), false)\n#2 
/xxxxxxxxxxxx/public_html/classes/order/OrderHistory.php(468): OrderHistoryCore->sendEmail(Object(Order), Array)\n#3
/xxxxxxxxxxxx/public_html/modules/cmcicpaiement/validation.php(109): OrderHistoryCore->addWithemail(true, Array)\n#4 
{main}\n  thrown in /xxxxxxxxxxxx/public_html/classes/Tools.php on line 801

flyman30 · July 22, 2019

C'est quand même un scandale de publier des mises à jours de versions de Prestashop qui empêchent les paiements bancaires de fonctionner !

Les marchands ont autre choses à faire que d'installer des rustines sur les nouvelles versions de Prestashop.

flyman30 · July 22, 2019

Suite à mes rapports de bugs, ceci devrait être réglé par la version 1.7.6.1 a venir... Je vais donc rétro pédaler vers la version 1.7.5.2 qui elle permet de vendre normalement

tdf-mep · July 23, 2019

La 14608 ne corrige qu'une partie des problèmes.
La 14813 est clôturée (Duplicate of #14648) et la 14648 ne semble pas embarqué, pour l'instant, dans la 1.7.6.1 : https://github.com/PrestaShop/PrestaShop/milestone/56

J'espère que çà sera le cas (et qu'il n'y aura pas confusion entre ces différents rapport de bug) car ont est plutôt sur un bug majeur là !

NB : le module cmcicpaiement est développé par Prestashop

digeek · July 23, 2019

Bonjour,

Nous avons aussi des soucis le Sogenactif 2.0 qui ne valide plus les commandes (statut inexistant malgré paiement ok) en 1.7.6.0

(je passe le soucis de la table ps_currency...)

On essaie de débugger de notre côté.

SuperPseudo1234 · July 23, 2019

Bonjour à tous,

Je rencontre les mêmes difficultés avec E-transaction (Crédit Agricole / Paybox). Après avoir corrigé la table ps_currency, je peux désormais passer des commandes mais ces dernières ne sont jamais validé. Et ce malgré le fait que les paiements sont bien effectués.

Voici un lien vers mon topic:

c00lsp0t · July 23, 2019

Bonjour,

Je viens de test avec le module de paiement cllicandpay du groupe crédit du nord et je n'ai pas de soucis.

En regardant la ligne 801 (du fichier classes/Tools.php) entre la nouvelle versionne prestashop 1.7.6 et les ancienne version c'est du à la suppression de la librairie CLDR. Le display price en version 1.7.5 se retournait de cette manière

$cldr = self::getCldr($context);

return $cldr->getPrice($price, is_array($currency) ? $currency['iso_code'] : $currency->iso_code);

Alors qu'en 1.7.6 c'est de cette manière :

$locale = static::getContextLocale($context);
$currencyCode = is_array($currency) ? $currency['iso_code'] : $currency->iso_code;

return $locale->formatPrice($price, $currencyCode);

en clair il retourne un prix formater suivant la locale de la nouvelle fonction getContextLocale.

Pour un fix temporaire et dégueu il faudrait peut etre remplacer le $locale = static::getContextLocale($context); par un $locale = $context->getCurrentLocale();
Mais ca ne pourrait peut etre marcher que sur les boutique mono langue vu que la locale serait celle de la boutique et qu'un site multilangue prendrait la currentlocale et pas la contextLocale et donc ca merderai pour ces site la.

Je vous avoue que je ne peut tester mes dire (vu que je n'ai pas ce soucis la) donc à prendre avec des pincettes mais peut etre que ca pourra vous avancer un peu

Edited July 23, 2019 by c00lsp0t (see edit history)

c00lsp0t · July 23, 2019

Sinon j'approuve certain d'entre vous ce bug est proprement scandaleux et hélas ca donne du grain à moudre à ceux qui conseille de ne jamais mettre à jour son prestashop sauf à faire une refonte lors de version majeur (basculement de 1.6 a 1.7 par exemple)

flyman30 · July 24, 2019

Il y a 7 heures, c00lsp0t a dit :
Bonjour,

Je viens de test avec le module de paiement cllicandpay du groupe crédit du nord et je n'ai pas de soucis.

En regardant la ligne 801 (du fichier classes/Tools.php) entre la nouvelle versionne prestashop 1.7.6 et les ancienne version c'est du à la suppression de la librairie CLDR. Le display price en version 1.7.5 se retournait de cette manière
$cldr = self::getCldr($context);

return $cldr->getPrice($price, is_array($currency) ? $currency['iso_code'] : $currency->iso_code);
Alors qu'en 1.7.6 c'est de cette manière :
$locale = static::getContextLocale($context);
$currencyCode = is_array($currency) ? $currency['iso_code'] : $currency->iso_code;

return $locale->formatPrice($price, $currencyCode);
en clair il retourne un prix formater suivant la locale de la nouvelle fonction getContextLocale.

Pour un fix temporaire et dégueu il faudrait peut etre remplacer le $locale = static::getContextLocale($context); par un $locale = $context->getCurrentLocale();
Mais ca ne pourrait peut etre marcher que sur les boutique mono langue vu que la locale serait celle de la boutique et qu'un site multilangue prendrait la currentlocale et pas la contextLocale et donc ca merderai pour ces site la.

Je vous avoue que je ne peut tester mes dire (vu que je n'ai pas ce soucis la) donc à prendre avec des pincettes mais peut etre que ca pourra vous avancer un peu

Tu veux dire que c'est ce changement qui fait qu'on ne reçoit pas les validations de la banque ???

digeek · July 24, 2019

Je viens de tester ton idée de fix (boutique mono langue), cela ne résout pas le soucis de validation des commandes.

On a mis des logs un peu partout lors de la validation bancaire mais tout semble ok.

Quelques éléments remarqués dans les logs lors d'une transaction.

[Tue Jul 23 12:46:46.407490 2019] [:error] [pid 163123:tid 140027266819840] [client 160.92.133.135:19330] FastCGI: server "/home/clients/e4cb1ca1a4bb2cef9b6243f15067ebaeaz/.config/apache/www.domain.tld/.fpm/php5.external" stderr: PHP message: PHP Fatal error: Uncaught Error: Call to a member function get() on null in /home/clients/e4cb1ca1a4bb2cef9b6243f15067ebaeaz/www.domain.tld/www/classes/Tools.php:801

[Tue Jul 23 12:46:46.407519 2019] [:error] [pid 163123:tid 140027266819840] [client 160.92.133.135:19330] FastCGI: server "/home/clients/e4cb1ca1a4bb2cef9b6243f15067ebaeaz/.config/apache/www.domain.tld/.fpm/php5.external" stderr: #3/home/clients/e4cb1ca1a4bb2cef9b6243f15067ebaeaz/www.domain.tld/www/modules/worldline/validation.php(179): Worldline->validate('465', '2', 37.95)

[Tue Jul 23 12:46:46.407517 2019] [:error] [pid 163123:tid 140027266819840] [client 160.92.133.135:19330] FastCGI: server "/home/clients/e4cb1ca1a4bb2cef9b6243f15067ebaeaz/.config/apache/www.domain.tld/.fpm/php5.external" stderr: #2/home/clients/e4cb1ca1a4bb2cef9b6243f15067ebaeaz/www.domain.tld/www/modules/worldline/worldline.php(762): PaymentModuleCore->validateOrder('465', '2', 37.95, 'Worldline', NULL, Array, NULL, false, '6c6619596a6b4e1...')

Et les éléments loggués lors du test de ce matin

2019-07-24 08:33:24 : Data : --== STATUT ==-- : $statut = 2
2019-07-24 08:33:24 : Data : --== responseCode = 00 ==-- : $statut = 2
2019-07-24 08:33:24 : Data : 3302855 ; 2 ; 925
2019-07-24 08:33:24 : Data : --== public function validate == $id_cart=330 ; $id_cart_key=330
2019-07-24 08:33:24 : Data : --== public function validateOrder ==
2019-07-24 08:33:24 : Data : $id_cart = 330 | $id_order_state = 2 | $amount_paid = 9.25 | $this->displayName = Worldline | $this->displayName = Worldline | $customer->secure_key = XXXXXXXXXXXXXXXXXXXXXXXXXXXX

flyman30 · July 24, 2019

A c00lsp0t

Peut-tu confirmer que la validation des paiement bancaire cllicandpay fonctionne pour toi après l'update 1.7.5.2 -> 1.7.6.0 ???

Si c'est le cas ce module fonctionne t'il avec PayBox ? Car si ce n'est pas le cas c'est peut-être PayBox le souci ...

cmcicpaiement
Sogenactif 2.0
E-Transaction

Sont contrôlés par PayBox.

c00lsp0t · July 24, 2019

Bonjour,

J'ai parlé un peu vite concernant mon module de paiement clicandpay. J'ai une errreur de notification d'url de retour (FAILED_SERVER_500_ERROR) qui m'a été envoyé par mon module de paiement à mon adresse email "technique" de mon site.

Par contre lors du processus de commande par le client tout va bien c'est à dire qu'il peut faire le paiement et qu'il peut retourner à la boutique sans erreur en ayant finaliser sa commande. Il reçoit un email de confirmation de paiement par mon module de paiement mais pas de confirmation de commande. Et dans le backoffice j'ai bien la nouvelle commande avec le bon montant mais elle n'a pas de statut "confirmé". Il faut que je la passe manuellement à ce statut.

Bref en fait j'ai le même problème que vous tous

Edited July 24, 2019 by c00lsp0t (see edit history)

Howie · July 24, 2019

Bonjour,

j'ai un problème de quelques commandes qui ne remontent pas dans le BO depuis quelques jours sur des paiements Paypal et CB (via Monetico CIC) sur un PS 1.7.5.2 :

"PaymentModule::validateOrder - Secure key does not match"

J'ai bien mes alertes dans le log du BO avec mes identifiants panier et date d'erreur.

Pouvez-vous me dire quelle(s) méthode(s) vous utilisez pour logger les erreurs autrement que via le BO ?

Les fichiers de log PHP ? Les logs via le site du mode de paiement ?

Merci pour votre aide.

c00lsp0t · July 24, 2019

1 hour ago, flyman30 said:

A c00lsp0t

Peut-tu confirmer que la validation des paiement bancaire cllicandpay fonctionne pour toi après l'update 1.7.5.2 -> 1.7.6.0 ???

Si c'est le cas ce module fonctionne t'il avec PayBox ? Car si ce n'est pas le cas c'est peut-être PayBox le souci ...

cmcicpaiement
Sogenactif 2.0
E-Transaction

Sont contrôlés par PayBox.

La validation de paiement se fait mais j'ai une erreur de retour de notification qui entraine sur mon back office prestashop un mauvais switch de status de la commande. Cependant lors du processus de paiement le client ne voit aucune erreur et peut payer normalement.

Edited July 24, 2019 by c00lsp0t (see edit history)

flyman30 · July 24, 2019

J'ai fait une installation neuve de Prestashop j'ai juste ajouté le module E-Transaction, il se produit le même bug !

Une fois qu'on a rentré ses donnée de carte bancaire la banque affiche un ticket avec paiement accepté, puis une page PrestaShop affiche "attente de validation" puis cette page fait 10 tentative et enfin le front-office la boutique s'ouvre...

Conclusion: Pas de commandes validé en paiement dans le BO, pas de mail au client, pas de mail au marchand.

Tout va bien madame la marquise.

flyman30 · July 24, 2019

il y a 36 minutes, Howie a dit :

Bonjour,

j'ai un problème de quelques commandes qui ne remontent pas dans le BO depuis quelques jours sur des paiements Paypal et CB (via Monetico CIC) sur un PS 1.7.5.2 :

"PaymentModule::validateOrder - Secure key does not match"

J'ai bien mes alertes dans le log du BO avec mes identifiants panier et date d'erreur.

Pouvez-vous me dire quelle(s) méthode(s) vous utilisez pour logger les erreurs autrement que via le BO ?

Les fichiers de log PHP ? Les logs via le site du mode de paiement ?

Merci pour votre aide.

Monetico te signale que les clés de sécurité ne correspondent pas !!!

flyman30 · July 24, 2019

D'après les développeurs de PrestaShop ce serai nos modules qui seraient en cause...

Ils m'ont demandés si le module e-transaction que j'utilisais était le module officiel vendu 200€ sur addon... Alors que celui fourni par le Crédit Agricole qui est gratuit à toujours fonctionné jusqu’à ce fameux update vers 1.7.6.0....

Je les soupçonne d'avoir modifié un truc qui empêche les modules non officiels de fonctionner.

Ils ont testés :

ps_wirepayment
ps_checkpayment
COD
PayPal

Avec succès

Donc j'ai peu d'espoir de résolution.

Edited July 24, 2019 by flyman30 (see edit history)

c00lsp0t · July 24, 2019

3 minutes ago, flyman30 said:

D'après les développeurs de PrestaShop ce serai nos modules qui seraient en cause...

Ils m'ont demandés si le module e-transaction que j'utilisais était le module officiel vendu 200€ sur addon... Alors que celui fourni par le Crédit Agricole qui est gratuit à toujours fonctionné jusqu’à ce fameux update vers 1.7.6.0....

Je les soupçonne d'avoir modifié un truc qui empêche les modules non officiels de fonctionner.

Ils ont testés :

ps_wirepayment

ps_checkpayment

COD

PayPal

Avec succès

Donc j'ai peu d'espoir de résolution.

Lol c'est du foutage de gueule. Mon module de paiement est fourni par ma banque sur leur site officiel et il n'est pas présent sur la boutique addon prestashop. Devoir faire un rollback en version 1.7.5.2 serait assez chiant parce que je perdrait 10 jours d'ajout de chose sur la base de données (modification de produits, etc...) Bref ce n'est pas envisageable.

Quant à leur si je comprend bien c'est un test par paypal et deux paiement qui ne passe pas par des service tiers de banque (paiement cheque et virement bancaire).

En plus c'est pas comme si un seul module merdait (et quand tu contacte les prestataire des module ils te disent bien que c'est pas eux mais prestashop le soucis vu qu'ils n'arrivent pas a envoyer la reponse sur ton prestashop et que chez eux ca se passe bien), mais la plupart des module de paiement merde.

digeek · July 24, 2019

2 hours ago, Howie said:

Bonjour,

j'ai un problème de quelques commandes qui ne remontent pas dans le BO depuis quelques jours sur des paiements Paypal et CB (via Monetico CIC) sur un PS 1.7.5.2 :

"PaymentModule::validateOrder - Secure key does not match"

J'ai bien mes alertes dans le log du BO avec mes identifiants panier et date d'erreur.

Pouvez-vous me dire quelle(s) méthode(s) vous utilisez pour logger les erreurs autrement que via le BO ?

Les fichiers de log PHP ? Les logs via le site du mode de paiement ?

Merci pour votre aide.

Tu peux logguer tes données dans un fichier txt

$logData = '--== hookOrderConfirmation ==--'; 
file_put_contents('debug_'.date("Ymd").'.txt', PHP_EOL.date("Y-m-d H:i:s").' : Data : '.$logData, FILE_APPEND);

c00lsp0t · July 24, 2019

Je viens un peu de check les log :

En prestashop 1.7.5 les log d'un paiement réussi sont comme cela

*INFO* 	v1.7.5.2	2019/06/27 - 20:31:39: Server call process starts for cart #74.
*INFO* 	v1.7.5.2	2019/06/27 - 20:31:39: Payment accepted for cart #74. New order state is 2.
*INFO* 	v1.7.5.2	2019/06/27 - 20:31:39: Create order for cart #74.
*INFO* 	v1.7.5.2	2019/06/27 - 20:31:42: Order #15 created successfully for cart #74.
*INFO* 	v1.7.5.2	2019/06/27 - 20:31:42: Save payment information for cart #74.
*INFO* 	v1.7.5.2	2019/06/27 - 20:31:42: Payment information with ID(s) 24 saved successfully for cart #74.

Alors qu'un paiement en 1.7.6 :

*INFO* 	v1.7.6.0	2019/07/24 - 00:41:16: Server call process starts for cart #108.
*INFO* 	v1.7.6.0	2019/07/24 - 00:41:16: Payment accepted for cart #108. New order state is 2.
*INFO* 	v1.7.6.0	2019/07/24 - 00:41:16: Create order for cart #108.
*INFO* 	v1.7.6.0	2019/07/24 - 00:41:26: User return to shop process starts for cart #108.
*INFO* 	v1.7.6.0	2019/07/24 - 00:41:26: Order already registered for cart #108.
*INFO* 	v1.7.6.0	2019/07/24 - 00:41:26: The current state for order corresponding to cart #108 is (0).
*WARNING* 	v1.7.6.0	2019/07/24 - 00:41:26: Unknown order state ID (0) for cart #108. Managed by merchant.
*INFO* 	v1.7.6.0	2019/07/24 - 00:41:26: Payment success for cart #108. Redirect to success page.

En clair il y a un probleme dans le processus de creation de commande dans le BO apres le paiement du panier.

Lorsque je vais dans le fichier validation.php de mon module j'ai cette fonction la qui correspond a des entré de mes log

$logger->logInfo("Payment accepted for cart #$cart_id. New order state is $new_state.");

$order = $clicandpay->saveOrder($cart, $new_state, $response);

Et apres ca plus de log OK. C'est dans la creation de sauvegarde qu'il y a un pb depuis la 1.7.6.

Lorsque je vais sur la methode saveOrder de mon module j'ai

$this->logger->logInfo("Create order for cart #{$cart->id}.");

        // retrieve customer from cart
        $customer = new Customer((int)$cart->id_customer);

        $currency = ClicandpayApi::findCurrency($response->get('currency'));
        $decimals = $currency->getDecimals();

        // PrestaShop id_currency from currency iso num code
        $currency_id = Currency::getIdByIsoCode($currency->getAlpha3());

        // real paid total on gateway
        $paid_total = $currency->convertAmountToFloat($response->get('amount'));
        if (number_format($cart->getOrderTotal(), $decimals) == number_format($paid_total, $decimals)) {
            // to avoid rounding issues and bypass PaymentModule::validateOrder() check
            $paid_total = $cart->getOrderTotal();
        }

        // call payment module validateOrder
        $this->validateOrder(
            $cart->id,
            $state,
            $paid_total,
            $response->get('order_info'), // title defined in admin panel and sent to gateway as order_info
            null, // $message
            array(), // $extraVars
            $currency_id, // $currency_special
            true, // $dont_touch_amount
            $customer->secure_key
        );

        // reload order
        $order = new Order((int)Order::getOrderByCartId($cart->id));
        $this->logger->logInfo("Order #{$order->id} created successfully for cart #{$cart->id}.");

        $this->createMessage($order, $response);
        $this->savePayment($order, $response);

        return $order;

Donc le premier message de log est bien appellé dans mes log mais pas ce qui suit le $this->validateOrder.

A savoir que cette méthode validateOrder correspond à la classe abstraite parente que mon module étend et qui est "/classes/PaymentModule.php

Je pense que le soucis vient de cette méthode la depuis la 1.7.6. Mais j'avoue que j'ai pas de moyen facile pour faire un debug de ce methode

c00lsp0t · July 24, 2019

En faisant un comparatif de la méthode validateOrder du fichier de la classe PaymentModule.php on s'aperçoit que 2 grosse partie ont été réécrite : la première partie sur la construction de l'objet Order et la deuxième concernant les taxes.

Il faudrait voir peut etre que si on mettait l'ancienne façon de valider la commande ca pourrait peut etre temporairement corriger ce bug. Ou tout du moins se limiter à la premiere partie qui concerne la construction de la commande.

J'ai mis en PJ deux fichier :

- La méthode validateOrder en 1.7.6 => file-new.php

- La méthode validateOrder en 1.7.5.2 => file-old.php

Et je pense que c'est cette partie qui doit merder avec nos module de paiement :

Prestashop 1.7.5.2 :

foreach ($package_list as $id_address => $packageByAddress) {
                foreach ($packageByAddress as $id_package => $package) {
                    /** @var Order $order */
                    $order = new Order();
                    $order->product_list = $package['product_list'];

                    if (Configuration::get('PS_TAX_ADDRESS_TYPE') == 'id_address_delivery') {
                        $address = new Address((int) $id_address);
                        $this->context->country = new Country((int) $address->id_country, (int) $this->context->cart->id_lang);
                        if (!$this->context->country->active) {
                            throw new PrestaShopException('The delivery address country is not active.');
                        }
                    }

                    $carrier = null;
                    if (!$this->context->cart->isVirtualCart() && isset($package['id_carrier'])) {
                        $carrier = new Carrier((int) $package['id_carrier'], (int) $this->context->cart->id_lang);
                        $order->id_carrier = (int) $carrier->id;
                        $id_carrier = (int) $carrier->id;
                    } else {
                        $order->id_carrier = 0;
                        $id_carrier = 0;
                    }

                    $order->id_customer = (int) $this->context->cart->id_customer;
                    $order->id_address_invoice = (int) $this->context->cart->id_address_invoice;
                    $order->id_address_delivery = (int) $id_address;
                    $order->id_currency = $this->context->currency->id;
                    $order->id_lang = (int) $this->context->cart->id_lang;
                    $order->id_cart = (int) $this->context->cart->id;
                    $order->reference = $reference;
                    $order->id_shop = (int) $this->context->shop->id;
                    $order->id_shop_group = (int) $this->context->shop->id_shop_group;

                    $order->secure_key = ($secure_key ? pSQL($secure_key) : pSQL($this->context->customer->secure_key));
                    $order->payment = $payment_method;
                    if (isset($this->name)) {
                        $order->module = $this->name;
                    }
                    $order->recyclable = $this->context->cart->recyclable;
                    $order->gift = (int) $this->context->cart->gift;
                    $order->gift_message = $this->context->cart->gift_message;
                    $order->mobile_theme = $this->context->cart->mobile_theme;
                    $order->conversion_rate = $this->context->currency->conversion_rate;
                    $amount_paid = !$dont_touch_amount ? Tools::ps_round((float) $amount_paid, 2) : $amount_paid;
                    $order->total_paid_real = 0;

                    $order->total_products = (float) $this->context->cart->getOrderTotal(false, Cart::ONLY_PRODUCTS, $order->product_list, $id_carrier);
                    $order->total_products_wt = (float) $this->context->cart->getOrderTotal(true, Cart::ONLY_PRODUCTS, $order->product_list, $id_carrier);
                    $order->total_discounts_tax_excl = (float) abs($this->context->cart->getOrderTotal(false, Cart::ONLY_DISCOUNTS, $order->product_list, $id_carrier));
                    $order->total_discounts_tax_incl = (float) abs($this->context->cart->getOrderTotal(true, Cart::ONLY_DISCOUNTS, $order->product_list, $id_carrier));
                    $order->total_discounts = $order->total_discounts_tax_incl;

                    $order->total_shipping_tax_excl = (float) $this->context->cart->getPackageShippingCost((int) $id_carrier, false, null, $order->product_list);
                    $order->total_shipping_tax_incl = (float) $this->context->cart->getPackageShippingCost((int) $id_carrier, true, null, $order->product_list);
                    $order->total_shipping = $order->total_shipping_tax_incl;

                    if (!is_null($carrier) && Validate::isLoadedObject($carrier)) {
                        $order->carrier_tax_rate = $carrier->getTaxesRate(new Address((int) $this->context->cart->{Configuration::get('PS_TAX_ADDRESS_TYPE')}));
                    }

                    $order->total_wrapping_tax_excl = (float) abs($this->context->cart->getOrderTotal(false, Cart::ONLY_WRAPPING, $order->product_list, $id_carrier));
                    $order->total_wrapping_tax_incl = (float) abs($this->context->cart->getOrderTotal(true, Cart::ONLY_WRAPPING, $order->product_list, $id_carrier));
                    $order->total_wrapping = $order->total_wrapping_tax_incl;

                    $order->total_paid_tax_excl = (float) Tools::ps_round((float) $this->context->cart->getOrderTotal(false, Cart::BOTH, $order->product_list, $id_carrier), _PS_PRICE_COMPUTE_PRECISION_);
                    $order->total_paid_tax_incl = (float) Tools::ps_round((float) $this->context->cart->getOrderTotal(true, Cart::BOTH, $order->product_list, $id_carrier), _PS_PRICE_COMPUTE_PRECISION_);
                    $order->total_paid = $order->total_paid_tax_incl;
                    $order->round_mode = Configuration::get('PS_PRICE_ROUND_MODE');
                    $order->round_type = Configuration::get('PS_ROUND_TYPE');

                    $order->invoice_date = '0000-00-00 00:00:00';
                    $order->delivery_date = '0000-00-00 00:00:00';

                    if (self::DEBUG_MODE) {
                        PrestaShopLogger::addLog('PaymentModule::validateOrder - Order is about to be added', 1, null, 'Cart', (int) $id_cart, true);
                    }

                    // Creating order
                    $result = $order->add();

                    if (!$result) {
                        PrestaShopLogger::addLog('PaymentModule::validateOrder - Order cannot be created', 3, null, 'Cart', (int) $id_cart, true);
                        throw new PrestaShopException('Can\'t save Order');
                    }

                    // Amount paid by customer is not the right one -> Status = payment error
                    // We don't use the following condition to avoid the float precision issues : http://www.php.net/manual/en/language.types.float.php
                    // if ($order->total_paid != $order->total_paid_real)
                    // We use number_format in order to compare two string
                    if ($order_status->logable && number_format($cart_total_paid, _PS_PRICE_COMPUTE_PRECISION_) != number_format($amount_paid, _PS_PRICE_COMPUTE_PRECISION_)) {
                        $id_order_state = Configuration::get('PS_OS_ERROR');
                    }

                    $order_list[] = $order;

                    if (self::DEBUG_MODE) {
                        PrestaShopLogger::addLog('PaymentModule::validateOrder - OrderDetail is about to be added', 1, null, 'Cart', (int) $id_cart, true);
                    }

                    // Insert new Order detail list using cart for the current order
                    $order_detail = new OrderDetail(null, null, $this->context);
                    $order_detail->createList($order, $this->context->cart, $id_order_state, $order->product_list, 0, true, $package_list[$id_address][$id_package]['id_warehouse']);
                    $order_detail_list[] = $order_detail;

                    if (self::DEBUG_MODE) {
                        PrestaShopLogger::addLog('PaymentModule::validateOrder - OrderCarrier is about to be added', 1, null, 'Cart', (int) $id_cart, true);
                    }

                    // Adding an entry in order_carrier table
                    if (!is_null($carrier)) {
                        $order_carrier = new OrderCarrier();
                        $order_carrier->id_order = (int) $order->id;
                        $order_carrier->id_carrier = (int) $id_carrier;
                        $order_carrier->weight = (float) $order->getTotalWeight();
                        $order_carrier->shipping_cost_tax_excl = (float) $order->total_shipping_tax_excl;
                        $order_carrier->shipping_cost_tax_incl = (float) $order->total_shipping_tax_incl;
                        $order_carrier->add();
                    }
                }
            }

Prestashop 1.7.6 :

foreach ($package_list as $id_address => $packageByAddress) {
                foreach ($packageByAddress as $id_package => $package) {
                    $orderData = $this->createOrderFromCart(
                        $this->context->cart,
                        $this->context->currency,
                        $package['product_list'],
                        $id_address,
                        $this->context,
                        $reference,
                        $secure_key,
                        $payment_method,
                        $this->name,
                        $dont_touch_amount,
                        $amount_paid,
                        $package_list[$id_address][$id_package]['id_warehouse'],
                        $cart_total_paid,
                        self::DEBUG_MODE,
                        $order_status,
                        $id_order_state,
                        isset($package['id_carrier']) ? $package['id_carrier'] : null
                    );
                    $order = $orderData['order'];
                    $order_list[] = $order;
                    $order_detail_list[] = $orderData['orderDetail'];
                }
            }

Sachant que la nouvelle méthode prestashop 1.7.6 "createorderFromCart fait ceci :

protected function createOrderFromCart(
        Cart $cart,
        Currency $currency,
        $productList,
        $addressId,
        $context,
        $reference,
        $secure_key,
        $payment_method,
        $name,
        $dont_touch_amount,
        $amount_paid,
        $warehouseId,
        $cart_total_paid,
        $debug,
        $order_status,
        $id_order_state,
        $carrierId = null
    ) {
        $order = new Order();
        $order->product_list = $productList;

        if (Configuration::get('PS_TAX_ADDRESS_TYPE') == 'id_address_delivery') {
            $address = new Address((int) $addressId);
            $context->country = new Country((int) $address->id_country, (int) $cart->id_lang);
            if (!$context->country->active) {
                throw new PrestaShopException('The delivery address country is not active.');
            }
        }

        $carrier = null;
        if (!$cart->isVirtualCart() && isset($carrierId)) {
            $carrier = new Carrier((int) $carrierId, (int) $cart->id_lang);
            $order->id_carrier = (int) $carrier->id;
            $carrierId = (int) $carrier->id;
        } else {
            $order->id_carrier = 0;
            $carrierId = 0;
        }

        $order->id_customer = (int) $cart->id_customer;
        $order->id_address_invoice = (int) $cart->id_address_invoice;
        $order->id_address_delivery = (int) $addressId;
        $order->id_currency = $currency->id;
        $order->id_lang = (int) $cart->id_lang;
        $order->id_cart = (int) $cart->id;
        $order->reference = $reference;
        $order->id_shop = (int) $context->shop->id;
        $order->id_shop_group = (int) $context->shop->id_shop_group;

        $order->secure_key = ($secure_key ? pSQL($secure_key) : pSQL($context->customer->secure_key));
        $order->payment = $payment_method;
        if (isset($name)) {
            $order->module = $name;
        }
        $order->recyclable = $cart->recyclable;
        $order->gift = (int) $cart->gift;
        $order->gift_message = $cart->gift_message;
        $order->mobile_theme = $cart->mobile_theme;
        $order->conversion_rate = $currency->conversion_rate;
        $amount_paid = !$dont_touch_amount ? Tools::ps_round((float) $amount_paid, _PS_PRICE_COMPUTE_PRECISION_) : $amount_paid;
        $order->total_paid_real = 0;

        $order->total_products = (float) $cart->getOrderTotal(false, Cart::ONLY_PRODUCTS, $order->product_list, $carrierId);
        $order->total_products_wt = (float) $cart->getOrderTotal(true, Cart::ONLY_PRODUCTS, $order->product_list, $carrierId);
        $order->total_discounts_tax_excl = (float) abs($cart->getOrderTotal(false, Cart::ONLY_DISCOUNTS, $order->product_list, $carrierId));
        $order->total_discounts_tax_incl = (float) abs($cart->getOrderTotal(true, Cart::ONLY_DISCOUNTS, $order->product_list, $carrierId));
        $order->total_discounts = $order->total_discounts_tax_incl;

        $order->total_shipping_tax_excl = (float) $cart->getPackageShippingCost($carrierId, false, null, $order->product_list);
        $order->total_shipping_tax_incl = (float) $cart->getPackageShippingCost($carrierId, true, null, $order->product_list);
        $order->total_shipping = $order->total_shipping_tax_incl;

        if (null !== $carrier && Validate::isLoadedObject($carrier)) {
            $order->carrier_tax_rate = $carrier->getTaxesRate(new Address((int) $cart->{Configuration::get('PS_TAX_ADDRESS_TYPE')}));
        }

        $order->total_wrapping_tax_excl = (float) abs($cart->getOrderTotal(false, Cart::ONLY_WRAPPING, $order->product_list, $carrierId));
        $order->total_wrapping_tax_incl = (float) abs($cart->getOrderTotal(true, Cart::ONLY_WRAPPING, $order->product_list, $carrierId));
        $order->total_wrapping = $order->total_wrapping_tax_incl;

        $order->total_paid_tax_excl = (float) Tools::ps_round((float) $cart->getOrderTotal(false, Cart::BOTH, $order->product_list, $carrierId), _PS_PRICE_COMPUTE_PRECISION_);
        $order->total_paid_tax_incl = (float) Tools::ps_round((float) $cart->getOrderTotal(true, Cart::BOTH, $order->product_list, $carrierId), _PS_PRICE_COMPUTE_PRECISION_);
        $order->total_paid = $order->total_paid_tax_incl;
        $order->round_mode = Configuration::get('PS_PRICE_ROUND_MODE');
        $order->round_type = Configuration::get('PS_ROUND_TYPE');

        $order->invoice_date = '0000-00-00 00:00:00';
        $order->delivery_date = '0000-00-00 00:00:00';

        if ($debug) {
            PrestaShopLogger::addLog('PaymentModule::validateOrder - Order is about to be added', 1, null, 'Cart', (int) $cart->id, true);
        }

        // Creating order
        $result = $order->add();

        if (!$result) {
            PrestaShopLogger::addLog('PaymentModule::validateOrder - Order cannot be created', 3, null, 'Cart', (int) $cart->id, true);
            throw new PrestaShopException('Can\'t save Order');
        }

        // Amount paid by customer is not the right one -> Status = payment error
        // We don't use the following condition to avoid the float precision issues : http://www.php.net/manual/en/language.types.float.php
        // if ($order->total_paid != $order->total_paid_real)
        // We use number_format in order to compare two string
        if ($order_status->logable && number_format($cart_total_paid, _PS_PRICE_COMPUTE_PRECISION_) != number_format($amount_paid, _PS_PRICE_COMPUTE_PRECISION_)) {
            $id_order_state = Configuration::get('PS_OS_ERROR');
        }

        if ($debug) {
            PrestaShopLogger::addLog('PaymentModule::validateOrder - OrderDetail is about to be added', 1, null, 'Cart', (int) $cart->id, true);
        }

        // Insert new Order detail list using cart for the current order
        $order_detail = new OrderDetail(null, null, $context);
        $order_detail->createList($order, $cart, $id_order_state, $order->product_list, 0, true, $warehouseId);

        if ($debug) {
            PrestaShopLogger::addLog('PaymentModule::validateOrder - OrderCarrier is about to be added', 1, null, 'Cart', (int) $cart->id, true);
        }

        // Adding an entry in order_carrier table
        if (null !== $carrier) {
            $order_carrier = new OrderCarrier();
            $order_carrier->id_order = (int) $order->id;
            $order_carrier->id_carrier = $carrierId;
            $order_carrier->weight = (float) $order->getTotalWeight();
            $order_carrier->shipping_cost_tax_excl = (float) $order->total_shipping_tax_excl;
            $order_carrier->shipping_cost_tax_incl = (float) $order->total_shipping_tax_incl;
            $order_carrier->add();
        }

        return ['order' => $order, 'orderDetail' => $order_detail];
    }

file-old.php

file-new.php

flyman30 · July 24, 2019

Il y a 1 heure, c00lsp0t a dit :

Lol c'est du foutage de gueule. Mon module de paiement est fourni par ma banque sur leur site officiel et il n'est pas présent sur la boutique addon prestashop. Devoir faire un rollback en version 1.7.5.2 serait assez chiant parce que je perdrait 10 jours d'ajout de chose sur la base de données (modification de produits, etc...) Bref ce n'est pas envisageable.

Quant à leur si je comprend bien c'est un test par paypal et deux paiement qui ne passe pas par des service tiers de banque (paiement cheque et virement bancaire).

En plus c'est pas comme si un seul module merdait (et quand tu contacte les prestataire des module ils te disent bien que c'est pas eux mais prestashop le soucis vu qu'ils n'arrivent pas a envoyer la reponse sur ton prestashop et que chez eux ca se passe bien), mais la plupart des module de paiement merde.

Alors après bien des palabres sur github, ils ont enfin testé le module e-transaction que je leur ai fourni et bingo ils arrivent à la même constatation que nous, par contre pas de solutions pour le moment.

regarde : https://github.com/PrestaShop/PrestaShop/issues/14648#issuecomment-514604816

c00lsp0t · July 24, 2019

Bon finalement c'est peut etre pas ca non plus. En comparant la méthode createOrderFromCart avec la partie faisant la même chose en 1.7.5.2 c'est stricto la même chose. La seul différence est sur la ligne

$amount_paid = !$dont_touch_amount ? Tools::ps_round((float) $amount_paid, 2) : $amount_paid;

qui correspond en 1.7.6 :

$amount_paid = !$dont_touch_amount ? Tools::ps_round((float) $amount_paid, _PS_PRICE_COMPUTE_PRECISION_) : $amount_paid;

Ou la précision qui était inscrit en dur à 2 passe par la constance défini "_PS_PRICE_COMPUTE_PRECISION_"

Bref je sèche me concernant. Si quelqu'un aurait une autre piste ?

flyman30 · July 24, 2019

Si je savais faire ça fait longtemps que je t'aurais aidé

c00lsp0t · July 24, 2019

5 minutes ago, flyman30 said:

Si je savais faire ça fait longtemps que je t'aurais aidé

J'ai un message en cours de validation modérateur se rapportant plus en détail à ce que j'ai recherché.

C'est dommage je sens qu'on est pas loin du problème mais j'arrive pas à mettre la main dessus

flyman30 · July 24, 2019

Il y a quand même un peu d'espoir car le topic est passé en bug Majeur...

c00lsp0t · July 24, 2019

Dire que j'ai fait cette MAJ de version mineure parce que je voulais profiter du nouveau module d'avis client.

Finalement peut etre bien que la règle des MAJ prestashop c'est :

Pour une version 1.x vers 1.x+1 => Ne jamais mettre à jour, il faut faire une refonte complète
Pour une version 1.x.y vers 1.x.y+1 => Procéder à la MAJ après 3 à 6 mois après la sortie ou du moins attendre une version 1.x.y+1.1

Pour une version 1.x.y.z vers 1.x.y.z+1 => On peut faire une MAJ sans sourciller vu que ce n'est que des correctif de bug.

🤣

Edited July 24, 2019 by c00lsp0t (see edit history)

SuperPseudo1234 · July 24, 2019

Il semblerait que ce soit bien un problème causé par la 1.7.6. Du coup rétrogradage en 1.7.5.2 pour moi !

c00lsp0t · July 24, 2019

Dans le backoffice de mon module de gestion de paiement CB l'erreur qu'il me sort dans le detail est :

FAILED_SERVER_500_ERROR, rule=URL de notification à la fin du paiement, duration=~0,9s, response= null

Pas super précis hélas

flyman30 · July 24, 2019

Ça a l'air de bouger chez Prestashop ...

Citation

jcpaybox commented 36 minutes ago •

edited

so far we still haven't found why the validateOrder process does not finish.
debug seems to show that Tools::displayPrice could be the last function called, in the validateOrder method, when building the $product_var_tpl array.

Contributor

khouloudbelguith commented 7 minutes ago

Citation

Hi Adrien,

I just received the module clicandpay
https://drive.google.com/file/d/1VneFWdx6IsxeTX2IP97hDeDa9jQm9Yu3/view
I checked it with PS1.7.6.0 & PS1.7.5.2 => I have issues.

Thanks!

flyman30 · July 24, 2019

il y a 52 minutes, SuperPseudo1234 a dit :

Il semblerait que ce soit bien un problème causé par la 1.7.6. Du coup rétrogradage en 1.7.5.2 pour moi !

J'aimerai bien faire pareil sauf que j'ai perdu les sauvegardes 1.7.5.2 il ne me reste que celle de le 1.7.6.0 pas de bol !!

c00lsp0t · July 24, 2019

6 minutes ago, flyman30 said:

J'aimerai bien faire pareil sauf que j'ai perdu les sauvegardes 1.7.5.2 il ne me reste que celle de le 1.7.6.0 pas de bol !!

Par contre c'est relou mon module de payment requiers des clé API sécurisé et donc en fournissant le module a la personne elle n'a pas pu faire le test.

Je sais pas non plus ce que va répondre le fournisseur du module à ce sujet que j'ai contacté.

flyman30 · July 24, 2019

il y a 1 minute, c00lsp0t a dit :

Par contre c'est relou mon module de payment requiers des clé API sécurisé et donc en fournissant le module a la personne elle n'a pas pu faire le test.

Je sais pas non plus ce que va répondre le fournisseur du module à ce sujet que j'ai contacté.

Oui j'ai lu son commentaire, e-transaction est fourni avec une clé pour les tests

c00lsp0t · July 24, 2019

Just now, flyman30 said:

Oui j'ai lu son commentaire, e-transaction est fourni avec une clé pour les tests

J'ai bien une cle de test mais c'est associé à ma boutique et à l'url de celle-ci donc je suis pas sur que ca puisse marcher

flyman30 · July 24, 2019

il y a 1 minute, c00lsp0t a dit :

J'ai bien une cle de test mais c'est associé à ma boutique et à l'url de celle-ci donc je suis pas sur que ca puisse marcher

Ha oui ça n'est pas pratique.. comme je te l'ai dit mon module est fourni préparer pour les tests pour passer en mode production il faut générer un clé hmac de prod et paramètrer pour la boutique.

flyman30 · July 24, 2019

Il y a 3 heures, c00lsp0t a dit :

En faisant un comparatif de la méthode validateOrder du fichier de la classe PaymentModule.php on s'aperçoit que 2 grosse partie ont été réécrite : la première partie sur la construction de l'objet Order et la deuxième concernant les taxes.

Il faudrait voir peut etre que si on mettait l'ancienne façon de valider la commande ca pourrait peut etre temporairement corriger ce bug. Ou tout du moins se limiter à la premiere partie qui concerne la construction de la commande.

J'ai mis en PJ deux fichier :

- La méthode validateOrder en 1.7.6 => file-new.php

- La méthode validateOrder en 1.7.5.2 => file-old.php

file-new.php

Comment tu pense faire ces modifs ? je peut tester sur mon site de test au besoin.

Edited July 24, 2019 by flyman30 (see edit history)

c00lsp0t · July 24, 2019

2 hours ago, flyman30 said:

Comment tu pense faire ces modifs ? je peut tester sur mon site de test au besoin.

Je comptais faire un truc sale a base de copier l'ancienne methode pour l'ecraser dans la nouvelle methode dans le fichier PaymentModule.php.

En gros dans le fichier /classes/PaymentModule.php remplacer la méthode validateOrder du fichier en 1.7.6 par celle contenu dans le fichier de l'archive prestashop 1.7.5.2 qu'on peut dl sur prestashop

Mais quand j'ai regardé un comparatif ya pas tant que ca de diff en fait et donc je doute au final que ca vienne de cette partie la. (d'ou mon post d'apres ou je seche)

Edited July 24, 2019 by c00lsp0t (see edit history)

flyman30 · July 25, 2019

J'ai testé ta solution, bien entendu ça ne fonctionne pas.

Finalement ils commence à comprendre notre problème et à nous prendre au sérieux : https://github.com/PrestaShop/PrestaShop/issues/14648

tdf-mep · July 25, 2019

Les paiements PayPal sont également impactés.

J'ai vu vos différents commentaires sur https://github.com/PrestaShop/PrestaShop/issues/14648 .

C'est quand même dingue que ce bug ne soit pas d'avantage priorisé (déclaré depuis 10 jours et toujours pas embarqué dans la prochaine release) : il s'agit quand même de la fonctionnalité de base d'une boutique e-commerce => pouvoir payer ses achats !

Edited July 25, 2019 by tdf-mep (see edit history)

digeek · July 25, 2019

Nous avons du Paypal (en sandbox pour l'instant) sur la boutique qui rencontre le soucis des paiements.

Les paiements réalisés sont bien validés (à contrario des paiements Sogenactif 2.0)

c00lsp0t · July 25, 2019

29 minutes ago, digeek said:

Nous avons du Paypal (en sandbox pour l'instant) sur la boutique qui rencontre le soucis des paiements.

Les paiements réalisés sont bien validés (à contrario des paiements Sogenactif 2.0)

Tu veut dire que sur sogenactif meme le paiement ne se valide pas ? Ce n'est pas comme nous avec un paiement validé sur le site bancaire mais avec un retour sur prestashop sans status de commande ou sans creation de commande ?

Si c'est ca je t'invite si ce n'est pas déjà fait à poster tes log de Sogenactif sur le github du problème : https://github.com/PrestaShop/PrestaShop/issues/14648

Bref ce bug dans mon cas n'empeche pas le paiement mais reste quand même très problématique puisque il faut traiter en manuel la commande des reception de celle-ci pour lui changer de status et renvoyer les email au client. De mon point de vue c'est un problème critique qui devrait avoir la top priorité de fix.

Edited July 25, 2019 by c00lsp0t (see edit history)

digeek · July 25, 2019

Je suis dans le même cas que tout le monde.

Le paiement ne génère pas d'erreur, mais la commande se retrouve avec un statut 0 dans la bdd (et n'est donc pas validée).

c00lsp0t · July 25, 2019

Just now, digeek said:

Je suis dans le même cas que tout le monde.

Le paiement ne génère pas d'erreur, mais la commande se retrouve avec un statut 0 dans la bdd (et n'est donc pas validée).

Ok.

Le plus génant c'est que nous n'avons pas de solution de contournement à mettre en place le temps du fix. Même pas de "bidouille" meme "crade" pour faire fonctionner la chose le temps que ce problème soit corrigé.

tdf-mep · July 25, 2019

30 minutes ago, digeek said:

Nous avons du Paypal (en sandbox pour l'instant) sur la boutique qui rencontre le soucis des paiements.

Les paiements réalisés sont bien validés (à contrario des paiements Sogenactif 2.0)

Pour PayPal :

Erreur affiché au client (cf screenshot) Erreur de validation de la commande : The locale 2 is invalid. Votre paiement a été effectué. Contactez le Service clientèle.
Paiement accepté (PayPal envoie un mail de confirmation)
Dans le back office : état de la commande non mise à jour
Je pensé qu'il s'agissait du même problème, mais après vérification, pas d'erreur dans les log serveur ToolsCore::displayPrice => ToolsCore::getContextLocale(Object(Context)) => peut être qu'il s'agit d'un autre problème, je vais creuser

NB : test Paypal également réalisé après mise à jour manuel de la table ps_currency ( numeric_iso_code & precision cf : https://github.com/PrestaShop/PrestaShop/issues/14608 )

Pour CM-CIC P@iement (cf deuxième post de ce thread) :

Paiement accepté
Pas d'erreur affiché au client
Dans les log serveur, visiblement comme sur beaucoup d'autre module de paiement, erreur ToolsCore::displayPrice => ToolsCore::getContextLocale(Object(Context))
Dans le back office : état de la commande non mise à jour

NB : je ne suis pas sur que CM-CIC P@iement sont contrôlé par PayBox comme indiqué par plus haut dans ce thread par flyman30

digeek · July 25, 2019

@tdf-mep > as tu pensé a modifier la colonne precision a 2 au lieu de 6 dans la table ps_currency ?

tdf-mep · July 25, 2019

Oui comme indiqué dans mon post précédent :

Quote

NB : test Paypal également réalisé après mise à jour manuel de la table ps_currency ( numeric_iso_code & precision cf : https://github.com/PrestaShop/PrestaShop/issues/14608 )

flyman30 · July 26, 2019

Je pense que beaucoups de monde va être dans la mouise...

cette réponse de dévelopeur fait peur, ça voudrait dire que pratiquement tous les modules de paiement bancaires ne sont pas adaptés au nouveau core de PrestShop....

Citation

I think this comment points in the right direction.

I don't have access to the module's source code, but it looks like they are using custom endpoints and side-stepping PrestaShop's router. This is a bad practice and is strongly discouraged because when you do that, things like this happen.

Basically Tools now expects a certain environment to be available, in particular, it needs the service container to be initialized so that it can use the CLDR service to format prices. This environment is available whenever you use a PrestaShop controller, but not when accessing a module file directly (PS has no control over it).

I'd suggest module developers to build a FrontController to handle validation instead of a custom endpoint like validation.php.

To be clear: to my best understanding this issue must be addressed by module developers, it's not a bug in the core.

c00lsp0t · July 26, 2019

9 minutes ago, flyman30 said:

Je pense que beaucoups de monde va être dans la mouise...

cette réponse de dévelopeur fait peur, ça voudrait dire que pratiquement tous les modules de paiement bancaires ne sont pas adaptés au nouveau core de PrestShop....

Oui cette réponse est vraiment relou. Ca veut dire qu'ils ne vont rien faire et mettre les développeurs de module en faute. Ca va aussi dépendre de la réactivité des developpeur de module sachant qu'on est en juillet.

Après d'apres sa réponse ca pourrait ne pas etre si long à developper puisque ca serait changer le paradigme de validation.php qui n'est qu'un fichier php de code par l'ajout d'une classe validation qui etend la classe FrontController. Ensuite il faudrait mettre le code de validation.php dans une methode validate() par exemple et faire appel à cette méthode de la classe validation qui etend FrontController. (mais c'est cette partie qui risque d'etre plus tricky puisqu'il faudrait l'appeller au bon moment. Moment que je ne connais pas.)

Ou alors il faudrait voir comment est articuler leur module de méthode de paiment de prestashop des cheque et viremant bancaire et faire la meme chose

Edited July 26, 2019 by c00lsp0t (see edit history)

c00lsp0t · July 26, 2019

En gros dans le paiement par cheque il y a dans le dossier du module un fichier validation.php contenu dans controller/front/

Et ce fichier est sous la forme :

class Ps_CheckpaymentValidationModuleFrontController extends ModuleFrontController
{
    public function postProcess()
    {
        .....Code de validation
    }
}

Peut etre que notre solution est de modifier notre module creer ce front controller sous ce modele et foutre l'integralite du code de validation.php de notre module existant dans ce controller.

Ensuite par contre il faut voir comment l'appeller.

tdf-mep · July 26, 2019

2 hours ago, flyman30 said:

Je pense que beaucoups de monde va être dans la mouise...

cette réponse de dévelopeur fait peur, ça voudrait dire que pratiquement tous les modules de paiement bancaires ne sont pas adaptés au nouveau core de PrestShop....

C'est ni plus ni moins du grand n'importe quoi. On ne peut pas casser la compatibilité et bloquer autant de modules de paiement et ne rien vouloir faire pour les gens impactés. J'espère qu'il ne vont pas rester sur çà.

Voici le début du code source de CMCICPaiement :

<?php
/**
 * 2007-2015 PrestaShop
 *
 * DISCLAIMER
 *
 * Do not edit or add to this file if you wish to upgrade PrestaShop to newer
 * versions in the future. If you wish to customize PrestaShop for your
 * needs please refer to http://www.prestashop.com for more information.
 *
 * @author    PrestaShop SA <[email protected]>
 * @copyright 2007-2014 PrestaShop SA
 * @license   http://addons.prestashop.com/en/content/12-terms-and-conditions-of-use
 * International Registered Trademark & Property of PrestaShop SA
 */

use PrestaShop\PrestaShop\Core\Payment\PaymentOption;

class CMCICPaiement extends PaymentModule
 
    [...]
  
	public function __construct()
	{
		$this->name = 'cmcicpaiement';
		$this->version = '3.0.4';

		$this->page = basename(__FILE__, '.php');
		$this->bootstrap = true;
		$this->author = 'PrestaShop';

Développé par Prestashop visiblement : pas de mise à jour disponible pour l'instant...

Edited July 26, 2019 by tdf-mep (see edit history)

c00lsp0t · July 26, 2019

res honnetement vu le nombre de module touché il pourrait faire un patch de rétro-compatibilité avec l'ancienne méthode sans le "container". Ca serait crade comme le dit le lead dev presta mais ca marcherai et ca permettrait au developpeur de module de leur laisser le temps de recoder leur méthode de validation "proprement"

c00lsp0t · July 26, 2019

Bon j'ai essayer de créer un FrontController dans controllers/front en l'appellant validation. php et ayant le code suivant :

class ClicandpayValidationModuleFrontController extends ModuleFrontController
{
	/**
     * @see FrontController::postProcess()
     */
    public function postProcess()
    {

        /* module logger object */
        $logger = ClicandpayTools::getLogger();

        $save_on_failure = true;

        if (ClicandpayTools::checkRestIpnValidity()) {
            $test_mode = Configuration::get('CLICANDPAY_MODE') === 'TEST';
            $sha_key = $test_mode ? Configuration::get('CLICANDPAY_STD_PRIVKEY_TEST') : Configuration::get('CLICANDPAY_STD_PRIVKEY_PROD');

            /* use direct post content to avoid stipslashes from json data */
            $data = $_POST;

            if (!ClicandpayTools::checkHash($data, $sha_key)) {
                $ip = Tools::getRemoteAddr();
                $logger->logError("{$ip} tries to access validation.php page without valid signature with data: " . print_r($data, true));
                die('<span style="display:none">KO-An error occurred while computing the signature.' . "\n" . '</span>');
            }

            $answer = json_decode($data['kr-answer'], true);
            if (!is_array($answer)) {
                $logger->logError('Invalid REST IPN request received. Content of kr-answer: ' . $data['kr-answer']);
                die('<span style="display:none">KO-Invalid IPN request received.' . "\n" . '</span>');
            }

            $save_on_failure &= isset($answer['orderCycle']) && ($answer['orderCycle'] === 'CLOSED');

            /* wrap payment result to use traditional order creation tunnel */
            $data = ClicandpayTools::convertRestResult($answer);

            $cart_id = (int) $data['vads_order_id'];

            /* shopping cart object */
            $cart = new Cart($cart_id);

            require_once _PS_MODULE_DIR_ . 'clicandpay/classes/ClicandpayResponse.php';

            /* patch for unrecieved metadata field */
            if (!isset($data['vads_order_info'])) {
                $payment = new ClicandpayStandardPayment();
                $data['vads_order_info'] = $payment->getTitle($cart->id_lang);
            }

            /** @var ClicandpayResponse $response */
            $response = new ClicandpayResponse($data, null, null, null);
        } elseif (ClicandpayTools::checkFormIpnValidity()) {
            $cart_id = (int) Tools::getValue('vads_order_id');

            /* shopping cart object */
            $cart = new Cart($cart_id);

            require_once _PS_MODULE_DIR_ . 'clicandpay/classes/ClicandpayResponse.php';

            /** @var ClicandpayResponse $response */
            $response = new ClicandpayResponse(
                $_POST,
                Configuration::get('CLICANDPAY_MODE'),
                Configuration::get('CLICANDPAY_KEY_TEST'),
                Configuration::get('CLICANDPAY_KEY_PROD'),
                Configuration::get('CLICANDPAY_SIGN_ALGO')
            );

            /* check the authenticity of the request */
            if (!$response->isAuthentified()) {
                $ip = Tools::getRemoteAddr();
                $logger->logError("{$ip} tries to access validation.php page without valid signature with data: " . print_r($_POST, true));
                $logger->logError('Signature algorithm selected in module settings must be the same as one selected in gateway Back Office.');

                die($response->getOutputForGateway('auth_fail'));
            }
        } else {
            $logger->logError('Invalid IPN request received. Content: ' . print_r($_POST, true));
            die('<span style="display:none">KO-Invalid IPN request received.' . "\n" . '</span>');
        }

        $logger->logInfo("Server call process starts for cart #$cart_id.");

/* cart errors */
        if (!Validate::isLoadedObject($cart)) {
            $logger->logError("Cart #$cart_id not found in database.");
            die('<span style="display:none">KO-Order not found.' . "\n" . '</span>');
        } elseif ($cart->nbProducts() <= 0) {
            $logger->logError("Cart #$cart_id was emptied before redirection.");
            die('<span style="display:none">KO-Empty cart detected before order processing.' . "\n" . '</span>');
        }

/* rebuild context */
        if (isset($cart->id_shop)) {
            $_GET['id_shop'] = $cart->id_shop;
            Context::getContext()->shop = Shop::initialize();
        }

        Context::getContext()->customer = new Customer((int) $cart->id_customer);
        Context::getContext()->customer->logged = 1;

        Context::getContext()->cart = $cart = new Cart((int) $cart_id); // reload cart to take into account customer group

        $address = new Address((int) $cart->id_address_invoice);
        Context::getContext()->country = new Country((int) $address->id_country);
        Context::getContext()->language = new Language((int) $cart->id_lang);
        Context::getContext()->currency = new Currency((int) $cart->id_currency);
        Context::getContext()->link = new Link();

/* module main object */
        $clicandpay = new Clicandpay();

/* search order in db */
        $order_id = Order::getOrderByCartId($cart_id);

        if ($order_id === false) {
            /* order has not been processed yet */

            $new_state = (int) Clicandpay::nextOrderState($response);

            if ($response->isAcceptedPayment()) {
                $logger->logInfo("Payment accepted for cart #$cart_id. New order state is $new_state.");

                $order = $clicandpay->saveOrder($cart, $new_state, $response);

                if (Clicandpay::hasAmountError($order)) {
                    /* amount paid not equals initial amount. */
                    $msg = "Error: amount paid {$order->total_paid_real} is not equal to initial amount {$order->total_paid}.";
                    $msg .= " Order is in a failed state, cart #$cart_id.";
                    $logger->logWarning($msg);

                    die($response->getOutputForGateway('ko', 'Total paid is different from order amount.'));
                } else {
                    /* response to server */
                    die($response->getOutputForGateway('payment_ok'));
                }
            } else {
                /* payment KO */
                $logger->logInfo("Payment failed for cart #$cart_id.");

                $save_on_failure &= (Configuration::get('CLICANDPAY_FAILURE_MANAGEMENT') === ClicandpayTools::ON_FAILURE_SAVE);
                if ($save_on_failure || Clicandpay::isOney($response)) {
                    /* save on failure option is selected or Oney payment */
                    $msg = Clicandpay::isOney($response) ? 'FacilyPay Oney payment' : 'Save on failure option is selected';
                    $logger->logInfo("$msg : save failed order for cart #$cart_id. New order state is $new_state.");
                    $order = $clicandpay->saveOrder($cart, $new_state, $response);

                    die($response->getOutputForGateway('payment_ko'));
                } else {
                    die($response->getOutputForGateway('payment_ko_bis'));
                }
            }
        } else {
            /* order already registered */
            $logger->logInfo("Order #$order_id already registered for cart #$cart_id.");

            $order = new Order((int) $order_id);
            $old_state = (int) $order->getCurrentState();

            $logger->logInfo("The current state for order corresponding to cart #$cart_id is ($old_state).");

            /* check if a total refund of order was made */
            $total_refund = false;

            if ($response->get('operation_type') === 'CREDIT') {
                $currency = ClicandpayApi::findCurrency($response->get('currency'));
                $decimals = $currency->getDecimals();
                $paid_total = $currency->convertAmountToFloat($response->get('amount'));

                if (number_format($order->total_paid_real, $decimals) === number_format($paid_total, $decimals)) {
                    $total_refund = true;
                }
            }

            $outofstock = Clicandpay::isOutOfStock($order);
            $new_state = (int) Clicandpay::nextOrderState($response, $total_refund, $outofstock);

            /* final states */
            $consistent_states = array(
                'PS_OS_OUTOFSTOCK_PAID', // override paid state since PrestaShop 1.6.1
                'CLICANDPAY_OS_PAYMENT_OUTOFSTOCK', // paid state for PrestaShop < 1.6.1
                'PS_OS_PAYMENT',
                'CLICANDPAY_OS_TRANS_PENDING',
                'PS_OS_REFUND',
                'PS_OS_CANCELED',
            );

            /* if the payment is not the first in sequence, do not update order state */
            $first_payment = ($response->get('sequence_number') === '1') || !$response->get('sequence_number');

            if (($old_state === $new_state) || !$first_payment) {
                /* no changes, just display a confirmation message */
                $logger->logInfo("No state change for order associated with cart #$cart_id, order remains in state ({$old_state}).");

                $clicandpay->savePayment($order, $response);
                $clicandpay->createMessage($order, $response);

                if ($response->isAcceptedPayment()) {
                    $msg = 'payment_ok_already_done';
                } else {
                    $msg = 'payment_ko_already_done';
                }

                die($response->getOutputForGateway($msg));
            } elseif (Clicandpay::isPaidOrder($order) &&
                (!Clicandpay::isStateInArray($new_state, $consistent_states) || ($response->get('url_check_src') === 'PAY'))) {
                /* order cannot move from final paid state to not completed states */
                $logger->logInfo("Order is successfully registered for cart #$cart_id but platform returns a payment error, transaction status is {$response->getTransStatus()}.");
                die($response->getOutputForGateway('payment_ko_on_order_ok'));
            } elseif (!$old_state || Clicandpay::isStateInArray($old_state, Clicandpay::getManagedStates())) {
                if (($old_state === Configuration::get('PS_OS_ERROR')) && $response->isAcceptedPayment() &&
                    Clicandpay::hasAmountError($order)) {
                    /* amount paid not equals initial amount. */
                    $msg = "Error: amount paid {$order->total_paid_real} is not equal to initial amount {$order->total_paid}.";
                    $msg .= " Order is in a failed state, cart #$cart_id.";
                    $logger->logWarning($msg);
                    die($response->getOutputForGateway('ko', 'Total paid is different from order amount.'));
                }

                if (!$old_state) {
                    $logger->logWarning("Current order state for cart #$cart_id is empty! Something went wrong. Try to set it anyway.");
                }

                $clicandpay->setOrderState($order, $new_state, $response);

                $logger->logInfo("Order is successfully updated for cart #$cart_id.");
                die($response->getOutputForGateway($response->isAcceptedPayment() ? 'payment_ok' : 'payment_ko'));
            } else {
                $logger->logWarning("Unknown order state ID ($old_state) for cart #$cart_id. Managed by merchant.");
                die($response->getOutputForGateway('ok', 'Unknown order status.'));
            }
        }

    }
}

En fait j'ai repris le code présent dans mon validation.php à la racine du module et je l'ai mis dans la méthode postProcess. J'ai fait ca parce que dans le module prestashop ps_wirepayment c'est un peu dans ce style la le code de validation.php à la racinne du module est repris dans le front controller validation qu'il nomme le nom du moduleValidationModuleFrontController

J'ai aussi ajouter dans le constructeur de la class main de mon module le nouveau frontcontroller

$this->controllers = array(..... 'validation');

Et bien malgré cela j'ai strictement les meme erreur à savoir que le paiement se fait bien mais la commande dans le BO n'a pas de status et j'ai une erreur de notification de retour de paiement sur le backoffice de mon module de paiement.

Les log sont aussi identique.

Donc soit j'ai oublié quelquechose soit ce n'est pas le seul pb qu'il y a concernant ce problème de paiement.

Bon j'ai tenté d'expliquer en anglais ma démarche sur le topic de bug prestashop du github : https://github.com/PrestaShop/PrestaShop/issues/14648

En espérant que je me fasse comprendre.

Edited July 27, 2019 by c00lsp0t (see edit history)

tdf-mep · July 27, 2019

Je viens d'envoyer un message au support du module CM-CIC / Monetico Paiement, module qui semble développé par Presatshop, (marqué comme compatible 1.7.6.0) : https://addons.prestashop.com/fr/paiement-carte-wallet/296-cm-cic-monetico-paiement-en-une-fois.html pour leur indiquer le dysfonctionnement et que le module ne semblai par respecter les conventions de développement Prestashop selon ce post https://github.com/PrestaShop/PrestaShop/issues/14648#issuecomment-515520400

Je vous communiquerai la réponse ici.

flyman30 · July 27, 2019

il y a 15 minutes, tdf-mep a dit :

Je viens d'envoyer un message au support du module CM-CIC / Monetico Paiement, module qui semble développé par Presatshop, (marqué comme compatible 1.7.6.0) : https://addons.prestashop.com/fr/paiement-carte-wallet/296-cm-cic-monetico-paiement-en-une-fois.html pour leur indiquer le dysfonctionnement et que le module ne semblai par respecter les conventions de développement Prestashop selon ce post https://github.com/PrestaShop/PrestaShop/issues/14648#issuecomment-515520400

Je vous communiquerai la réponse ici.

S'agit-il d'un module que tu as acheté sur addon ou d'un module fourni gratuitement par ta banque ?

Moi j'ai signalé à e-transaction ce qu'avais dit le developeur de PrestaShop au sujet des nouvelles règles à respecter et j'ai également envoyé un message au dévelopeur du module e-transaction "officiel" sur addon qui est égalament noté "comptatible Prestashop 1.7.6.0 pour savoir s'il était réllement compatibe c'est à dire s'il validatait le paiement de la commande en BO et déclanchait bien l'envoi des mails.

Dans les deux cas j'attends la réponse... (en même temps on est samedi)

tdf-mep · July 27, 2019

Il s'agit bien du module acheté 300€ TTC ici : https://addons.prestashop.com/fr/paiement-carte-wallet/296-cm-cic-monetico-paiement-en-une-fois.html

Edited July 27, 2019 by tdf-mep (see edit history)

Soyons Solidaire · July 27, 2019

Arrêtez de sauter sur les mises a jour , sauf si cela est une correction

c00lsp0t · July 27, 2019

7 minutes ago, TCHOUPI said:

Arrêtez de sauter sur les mises a jour , sauf si cela est une correction

On le saura pour la prochaine fois que les seule mise à jour où l'on peut sauter dessus c'est celle en 1.x.y.z+1

Après si ya des addons de paiement porté en 1.7.6 ca serait bien de voir qu'elle ont été les modification de faite entre la 1.7.5.2 et la 1.7.6 afin de prevenir un maximum de developper d'addon voir de permettre au marchant de bidouiller vite fait un fix.

Edited July 27, 2019 by c00lsp0t (see edit history)

tdf-mep · July 27, 2019

8 minutes ago, TCHOUPI said:

Arrêtez de sauter sur les mises a jour , sauf si cela est une correction

Il faut effectivement bien tester avant de faire une mise à jour. Ce que nous avons visiblement pas suffisamment fait. En même temps refaire une qualif complète avant chaque update c'est pas une paille. Il vaut mieux rester à jour régulière car certaine release corrigent des problèmes de sécurité.

Si une mise à jour est publié c'est qu'elle devrait être installable.

Au vu du problème et du nombre de modules impactés, dont certains semblent développés par Prestashop, il est peut être utile de voir ce qu'il peut être amélioré en termes de testing avant chaque release. Je ne suis pas en train de dire que facile, ni de minimiser le travail nécessaire mais je pense que la question se pose (de mon point de vue en tout cas) .

flyman30 · July 27, 2019

il y a 26 minutes, c00lsp0t a dit :

Après si ya des addons de paiement porté en 1.7.6 ca serait bien de voir qu'elle ont été les modification de faite entre la 1.7.5.2 et la 1.7.6 afin de prevenir un maximum de developper d'addon voir de permettre au marchant de bidouiller vite fait un fix.

tdf-mep dit qu'il a acheté sur addon son module qui est noté compatible 1.7.6.0 sur addon et qui à le même problème que nous !!!!

Soyons Solidaire · July 27, 2019

Après avoir testé la Ps 1.7.6. Avec certains modules j'ai eu quelques soucis moi aussi, Exemple problème de hook que j'ai signaler. Pour le moment je vous conseille de ne rien acheter et d'attendre qu'elle soit vraiment fonctionnel

Edited July 27, 2019 by TCHOUPI (see edit history)

tdf-mep · July 27, 2019

Merci pour le conseil, peut être un peu tard pour pas de mal personnes sur ce thread. Espérons que les autres vous liront avant de migrer sur cette version

c00lsp0t · July 27, 2019

Je pense que prestashop devrait mettre une affiche sur leur monté de version en disant qu'il est preferable d'attendre quelque mois avant chaque mise à jour afin de prévenir un maximum de personne.

Edited July 27, 2019 by c00lsp0t (see edit history)

Webmain · July 27, 2019

Bonsoir,

monetico a quelques problème au niveau de leur module avec la version 1.6 j’ai abandonne le module monetico pour le module cm-cic qui a la fonctionne monetico les urls de retour fonctionne très bien.

Bien sûr faut les renvoyer à monetico.

Jai remarquer aussi que quand on fait une mise à jours avec le module click1upgrade il y a pas mal de fonction manquante qu’une version fraîche 1.7.6.0

exeple j’ai fait une mise à jour boutique 1.7.6 avec le module est là pleins f eproblele que j’ai résolu travaille sur la base de donnés etc.

Jai ensuite fait une version dev avec une nouvelle installation 1.7.6.0 aucun problème j’ai migrer toutes les donnés du client vers cette nouvelle version fraîche et la tout fonctionne parfaitement aucun problème il y a beaucoup plus de fonction aussi.

Donc un conseille faire une une nouvelle version migrer les données et là tout sera régler.

c00lsp0t · July 27, 2019

2 hours ago, Esh-Network said:

Bonsoir,

monetico a quelques problème au niveau de leur module avec la version 1.6 j’ai abandonne le module monetico pour le module cm-cic qui a la fonctionne monetico les urls de retour fonctionne très bien.

Bien sûr faut les renvoyer à monetico.

Jai remarquer aussi que quand on fait une mise à jours avec le module click1upgrade il y a pas mal de fonction manquante qu’une version fraîche 1.7.6.0

exeple j’ai fait une mise à jour boutique 1.7.6 avec le module est là pleins f eproblele que j’ai résolu travaille sur la base de donnés etc.

Jai ensuite fait une version dev avec une nouvelle installation 1.7.6.0 aucun problème j’ai migrer toutes les donnés du client vers cette nouvelle version fraîche et la tout fonctionne parfaitement aucun problème il y a beaucoup plus de fonction aussi.

Donc un conseille faire une une nouvelle version migrer les données et là tout sera régler.

Tu fais ca comment ? :

Tu installe dans un dossier spécifique "dev" en creant une nouvelle BDD. Ensuite tu export de la base de données à transférer juste les données que tu importe dans la version dev et ensutie quand tu te co tu retrouve toutes tes données ?

Mais faut aussi rajouter les module non natif a l'installation de prestashop aussi non ?

flyman30 · July 28, 2019

Oui comment migres tu les données ça m'intéresse.

J'ai aussi installé une version 1.7.6.0 neuve sans aucune autre modifs que l'installation du module e-transaction sur un site de dev mais les problèmes de module de paiement sont exactement les mêmes !!

Webmain · July 28, 2019

Bonjour,

jutilise directement un module sur sur le addons pour la migration des données plus rapide et moins casse tête à faire manuellement.

Je creer un sous dossier dev donc dev.lesite une nouvelle base de donnés une fois l installation du nouveau prestashop effzctuer je configure les langues’ les devise etc comme sur l ancienne version ensuite avec le module de migration je suis le tutoriel puis je migre les données bien sur les modules non natifs il faut les réinstaller et configurer en générale sans prend 10 minutes et le thème aussi.

Les frais aisé de port aussi par contre à re configurer puis voilà c’est prêt en tout est pour tout 40 minutes

flyman30 · July 28, 2019

il y a 20 minutes, Esh-Network a dit :

Bonjour,

jutilise directement un module sur sur le addons pour la migration des données plus rapide et moins casse tête à faire manuellement.

C'est quoi ce module ??

Webmain · July 28, 2019

Désolé : https://addons.prestashop.com/fr/migration-donnees-sauvegarde/8934-outil-de-migration-prestashop.html?utm_source=addons&utm_medium=Homeslider&utm_campaign=migration-pro&utm_content=fr

Si jamais je fait aussi des offres pour le faire.

Bonne journée.

flyman30 · July 29, 2019

Le 27/07/2019 à 10:37 PM, Esh-Network a dit :

Bonsoir,

monetico a quelques problème au niveau de leur module avec la version 1.6 j’ai abandonne le module monetico pour le module cm-cic qui a la fonctionne monetico les urls de retour fonctionne très bien.

Bien sûr faut les renvoyer à monetico.

Jai remarquer aussi que quand on fait une mise à jours avec le module click1upgrade il y a pas mal de fonction manquante qu’une version fraîche 1.7.6.0

exeple j’ai fait une mise à jour boutique 1.7.6 avec le module est là pleins f eproblele que j’ai résolu travaille sur la base de donnés etc.

Jai ensuite fait une version dev avec une nouvelle installation 1.7.6.0 aucun problème j’ai migrer toutes les donnés du client vers cette nouvelle version fraîche et la tout fonctionne parfaitement aucun problème il y a beaucoup plus de fonction aussi.

Donc un conseille faire une une nouvelle version migrer les données et là tout sera régler.

Quelques questions:

- les modules monetico et cm-cic sont ils des modules Atos,ou passe t'ils par Paybox ?

Quels sont les problème avec la mise à jour clic1upgrade ?

- Quelles sont les fonctions manquantes ?

- Quels sont les problèmes que tu as du résoudre ? fichiers ? BBD ?

J'aimerai signaler ces disfonctionnements du module clic1upgrade sur Github pour éviter que ça recommence !

tdf-mep · July 29, 2019

Pour les tests réalisés de mon côté :

si la partie visible depuis le back office (je ne suis pas allé comparer chaque données une à une en base) : aucun problème visible sur les données suite à l'update. Je ne pense pas que l'erreur vienne des données au vue de l'erreur et du commentaire : https://github.com/PrestaShop/PrestaShop/issues/14648#issuecomment-515520400
Cm-CIC : je suppose ni Atos ni PayBox (rien de trouvé avec une recherche text sauf "Atos / Notification" sur un template de notification => résidu ?)
J'ai rajouter un commentaire sur https://github.com/PrestaShop/PrestaShop/issues/14648 pour le module CM-CIC => cela ne semble pas pour l'instant faire évoluer leur point de vue. Je reste relativement dérouté par l'approche : je peu comprendre qu'il veulent faire évoluer certaine fonctionnalités, que certain module soit mal codé (y compris certain de Presatshop?), mais rester sur cette position (pas de méthode deprecated pour une période transitoire) au vue du nombre de module impactés me semble quand même un peu "brusque". => si d'autre personne on le même problème avec un module de paiement il faut peut être alimenter ce post https://github.com/PrestaShop/PrestaShop/issues/14648 ...

NB : pas de réponse pour l'instant de la part du module Cm-CIC

Edited July 29, 2019 by tdf-mep (see edit history)

flyman30 · July 29, 2019

Oui ils s'entête en disant qu'ils l'on fait exprès pour que les développeurs de modules adoptent "les bonnes pratiques" et peut-être surtout vendre de nouveaux modules...

Sur Addon j'ai tenté de contacter le développeur du module e-transaction marqué "développé par Prestshop"

Nous verrons bien ce qu'il en est...

c00lsp0t · July 29, 2019

Oui apparement ils ne vont pas bouger de leur position donc suivant la réactivité de certain developpeur de modules ca peut prendre du temps.

J'ai vu qu'un des développeur a répondu sur mes interrogation (c'est moi webmastercoolspot).

Ce soir j'essayerai d'appliquer les conseil du dev pour faire les modif sur mon module de paiement. SI ca marche je vous tient au jus et j'essayerai de faire un tutorial complet de mise à jour pour vous aider. Si ca marche pas ben je serai pas plus avancé.

Edited July 29, 2019 by c00lsp0t (see edit history)

ttoine · July 29, 2019

En fait l'idée n'est pas de bouger de position ou pas, c'est plus compliqué que ça.

La modification présente en 1.7.6 (ce n'est pas vraiment une régression, pour le coup) est la conséquence d'un long développement pour implémenter CLDR, afin de gérer les monnaies et leurs affichage en fonction des langues et des pays des clients. C'est un standard utilisé dans de nombreux logiciels, il s'accompagne de beaucoup de bonnes pratiques, et c'est réellement un plus pour PrestaShop et ses utilisateurs, à tous niveaux.

Cependant, comme CLDR est une grosse brique technologique, permettre au comportement précédent de fonctionner à nouveau est plus complexe que simplement faire un revert sur un pull request.

Pour le moment, les deux équipes core et module de PrestaShop sont en train d'étudier les possibilités et voir s'il est possible de proposer une solution intermédiaire en 1.7.6.1, ou pas.

Ce qui me parait surprenant, c'est que seuls les modules des banques françaises semblent être impactés... Quid des banques étrangères qui proposent des solutions équivalentes aux marchands ?

tdf-mep · July 29, 2019

2 minutes ago, ttoine said:

En fait l'idée n'est pas de bouger de position ou pas, c'est plus compliqué que ça.

La modification présente en 1.7.6 (ce n'est pas vraiment une régression, pour le coup) est la conséquence d'un long développement pour implémenter CLDR, afin de gérer les monnaies et leurs affichage en fonction des langues et des pays des clients. C'est un standard utilisé dans de nombreux logiciels, il s'accompagne de beaucoup de bonnes pratiques, et c'est réellement un plus pour PrestaShop et ses utilisateurs, à tous niveaux.

Cependant, comme CLDR est une grosse brique technologique, permettre au comportement précédent de fonctionner à nouveau est plus complexe que simplement faire un revert sur un pull request.

Pour le moment, les deux équipes core et module de PrestaShop sont en train d'étudier les possibilités et voir s'il est possible de proposer une solution intermédiaire en 1.7.6.1, ou pas.

Ce qui me parait surprenant, c'est que seuls les modules des banques françaises semblent être impactés... Quid des banques étrangères qui proposent des solutions équivalentes aux marchands ?

Merci en tout cas de cette réponse, vous prenez visiblement le problème au sérieux et c'est tant mieux !

c00lsp0t · July 29, 2019

9 minutes ago, ttoine said:

En fait l'idée n'est pas de bouger de position ou pas, c'est plus compliqué que ça.

La modification présente en 1.7.6 (ce n'est pas vraiment une régression, pour le coup) est la conséquence d'un long développement pour implémenter CLDR, afin de gérer les monnaies et leurs affichage en fonction des langues et des pays des clients. C'est un standard utilisé dans de nombreux logiciels, il s'accompagne de beaucoup de bonnes pratiques, et c'est réellement un plus pour PrestaShop et ses utilisateurs, à tous niveaux.

Cependant, comme CLDR est une grosse brique technologique, permettre au comportement précédent de fonctionner à nouveau est plus complexe que simplement faire un revert sur un pull request.

Pour le moment, les deux équipes core et module de PrestaShop sont en train d'étudier les possibilités et voir s'il est possible de proposer une solution intermédiaire en 1.7.6.1, ou pas.

Ce qui me parait surprenant, c'est que seuls les modules des banques françaises semblent être impactés... Quid des banques étrangères qui proposent des solutions équivalentes aux marchands ?

Je peut comprendre le principe de vouloir améliorer la solution et virer ce qui ne vas pas mais il faut comprendre les marchand comme nous qui sont entre le marteau et l'enclume puisque qu'on s'aperçoit qu'on est dépendant des développeur de module qui n'ont pas mis à jour à temps avec "les bonnes pratiques". Et on devient dépendant alors de leur réactivité qui peut prendre un certain temps.

Sachant qu’apparemment cette "mauvaise pratique" date de longtemps mais qu'aucun développeur de module de paiement (du moins français) n'ont fait le correctif. C'est que ca doit pas etre si évident pour eux de le faire (ou alors c'est tout des feignasse mais j'en doute un peu)

Après effectivement peut etre nous avons eu la naïveté de mettre à jour notre boutique peu de temps après la publication de la version stable mais je trouve ca quand même dommage si on en revient à suivre les précepte de beaucoup de marchand qui préconisent de ne jamais mettre à jour nos boutique et de ne faire que des refonte tous les x années pour basculement de version majeur simplement.

P.S : sinon concernant le module de paiement que j'utilise (clicandpay) en fait il fait parti d'une multitude de module de paiement developpé par le meme groupe (Lyra Network). Donc en fait quand on va sur le github du lyra network (https://github.com/lyra/plugin-prestashop/releases) on s'aperçoit qu'il y a une liste de module de paiement qui ont tous le même problèmes :

BNPP_IRB_PrestaShop_1.5-1.7_v1.11.1.zip945 KB
ClicAndPay_By_groupe_Credit_du_Nord_PrestaShop_1.5-1.7_v1.11.1.zip1.37 MB
Cobro_Inmediato_PrestaShop_1.5-1.7_v1.11.1.zip1.15 MB
Lyra_PrestaShop_1.5-1.7_v1.11.1.zip1.11 MB
PayZen_IN_PrestaShop_1.5-1.7_v1.11.1.zip784 KB
PayZen_LAT_PrestaShop_1.5-1.7_v1.11.1.zip1.16 MB
PayZen_PrestaShop_1.5-1.7_v1.11.1.zip1.43 MB
Sogecommerce_PrestaShop_1.5-1.7_v1.11.1.zip1.35 MB
Systempay_PrestaShop_1.5-1.7_v1.11.1.zip1.1 MB

Donc j'imagine que ca va prendre un certain temps au developpeur de mettre à jour tous ces modules de paiement du même réseau.

Edited July 29, 2019 by c00lsp0t (see edit history)

ttoine · July 29, 2019

C'est le cas, l'entreprise et ses développeurs prennent le problème très au sérieux. Pour la partie strictement technique, merci de bien vouloir aller sur GitHub, du coup.

Pour la mise à jour, petit rappel:
1/ on sauvegarde
2/ on vérifie que tous les module et le thème sont bien à jour et compatibles avec la version cibles
3/ sachant que certains devs trichent et ne testent pas trop, on prend le temps de tester la mise à jour sur une boutique de tests, si possible avec le même serveur, pour être sûr que tout se passe bien
4/ on sauvegarde la production et on prévoit une procédure pour restaurer si besoin
5/ on fait la mise à jour
6/ on ne fait jamais ça un vendredi soir, ou la veille de partir en vacances, ou juste avant les soldes / le black friday mais pendant une période tranquille

Pour ce qui est des banques, sachant que ça ne leur pose pas de problème de laisser des distributeurs de billet de banque tourner avec Windows XP en 2019, c'est un problème culturel qu'on ne résoudra pas rapidement. Le fait est qu'elle ne mettent pas à jour leurs technos très souvent. Alors que c'est pourtant plutôt critique, la gestion des transactions financières.

flyman30 · July 29, 2019

Il y a 2 heures, ttoine a dit :

C'est le cas, l'entreprise et ses développeurs prennent le problème très au sérieux. Pour la partie strictement technique, merci de bien vouloir aller sur GitHub, du coup.

Pour la mise à jour, petit rappel:
1/ on sauvegarde
2/ on vérifie que tous les module et le thème sont bien à jour et compatibles avec la version cibles
3/ sachant que certains devs trichent et ne testent pas trop, on prend le temps de tester la mise à jour sur une boutique de tests, si possible avec le même serveur, pour être sûr que tout se passe bien
4/ on sauvegarde la production et on prévoit une procédure pour restaurer si besoin
5/ on fait la mise à jour
6/ on ne fait jamais ça un vendredi soir, ou la veille de partir en vacances, ou juste avant les soldes / le black friday mais pendant une période tranquille

Pour ce qui est des banques, sachant que ça ne leur pose pas de problème de laisser des distributeurs de billet de banque tourner avec Windows XP en 2019, c'est un problème culturel qu'on ne résoudra pas rapidement. Le fait est qu'elle ne mettent pas à jour leurs technos très souvent. Alors que c'est pourtant plutôt critique, la gestion des transactions financières.

Et pour e-transaction sachant que le module est sur addon je suppose que quelqu'un s'en occupe ? Car la banque (Crédit Lyonnais) me dit que leur module fonctionnait que donc c'est à prestashop de se débrouiller... Belle mentalité.

Citation

Bonjour,

Les différents problèmes que vous avez rencontrez sont lié à la mise à jour de Prestashop 1.7.6.

Notre module fonctionne parfaite sur les versions précédentes.

Le problème ne peut donc venir que de cette version de Prestashop.

Avez-vous essayé de rétrograder vers une version inférieur ?

Cordialement,

digeek · July 29, 2019

Pour ma part (Sogenactif 2.0), j'ai ouvert un ticket sur le site de vente de plugin.

Wait & See

c00lsp0t · July 30, 2019

C'est bon le paiement marche avec les modification que j'ai entamé et l'aide de la réponse du developper ethernoendless mon module de paiement fonctionne de nouveau niquel chrome.

Mes log :

INFO v1.7.6.0	2019/07/30 - 01:55:49: Form data generation for cart #127 with standard submodule.
INFO v1.7.6.0	2019/07/30 - 01:55:49: Data to be sent to payment gateway : Array
(
......
)

INFO v1.7.6.0	2019/07/30 - 01:55:59: Server call process starts for cart #127.
INFO v1.7.6.0	2019/07/30 - 01:55:59: Front Controller : Payment accepted for cart #127. New order state is 2.
INFO v1.7.6.0	2019/07/30 - 01:55:59: Create order for cart #127.
INFO v1.7.6.0	2019/07/30 - 01:56:02: Order #28 created successfully for cart #127.
INFO v1.7.6.0	2019/07/30 - 01:56:02: Save payment information for cart #127.
INFO v1.7.6.0	2019/07/30 - 01:56:02: Payment information with ID(s) 30 saved successfully for cart #127.
INFO v1.7.6.0	2019/07/30 - 01:56:06: User return to shop process starts for cart #127.
INFO v1.7.6.0	2019/07/30 - 01:56:06: Order already registered for cart #127.
INFO v1.7.6.0	2019/07/30 - 01:56:06: The current state for order corresponding to cart #127 is (2).
INFO v1.7.6.0	2019/07/30 - 01:56:06: No changes for order associated with cart #127, order remains in state (2).
INFO v1.7.6.0	2019/07/30 - 01:56:06: Payment success confirmed for cart #127.

Et le retour BO de ma commande qui a de nouveau un status ainsi que la reception des email client

La il est un peu tard mais demain après le taf je vous fais un tuto pas à pas avec capture d'écran pour que vous puissiez faire votre fix vous même en attendant un éventuel correctif des dev de module.

C'est pas si compliqué en vrai à faire c'est créer un controller, mettre presque tout le code de votre validation.php de la racinne vers votre nouveau front controllers créer avec la méthod postProcess(). Et ensuite il faut remplacer les appel de votre fichier racinne validation.php par le frontcontroller nouvellement créé (soit c'est dans la configuration du back office marchand (url de notification). Soit si c'est plus complexe à voir dans votre module.

Edited July 30, 2019 by c00lsp0t (see edit history)

flyman30 · July 30, 2019

Merci de ton retour j'attends avec avec impatience ton tuto.

ttoine · July 30, 2019

@flyman30 il faut envoyer au crédit lyonnais le lien vers le post d'eternoendless sur github et leur expliquer qu'il y a bien un problème technique dans leur module.

Au besoin ils peuvent me contacter, et nous prendrons le temps cde leur expliquer.

ttoine · July 30, 2019

@c00lsp0t merci pour ton retour !

Reste à faire en sorte que tous les éditeurs mettent à jour leurs modules aussi vite que toi...

c00lsp0t · July 30, 2019

Bon alors je vous explique de ce que j'ai fait pour que ca marche chez moi. Je ne peut garantir que ca ne marche chez vous mais c'est du moins la ligne directrice à suivre vu qu'on avais tous le même problème. A noter que j'utilise un système pour le paiement qui est une redirection de formulaire vers l'espace sécurisé de la banque (je ne sais pas si ma méthode marche avec des iframes intégré au site ou autre)

Comme l'a dit ethernoendless le principe est de remplacer la gestion du retour de paiement qui se fait via un fichier annexe à l'intérieur du module par un FrontControllerModule afin de "contenairisé" le traitement.

Donc normalement à la racine de votre module de paiement qui se trouve dans le dossier "modules" de prestashop vous devez avoir un fichier .php (dans mon cas il s'appelle "validation.php") qui s'occupe du traitement de retour de la banque. Le principe va être de deplacer le code contenu dans ce fichier dans un ModuleFrontController à l'intérieur du module de paiement

1) Il faut créer tout d'abord ce ModuleFrontContainer nommé validation.php que l'on va placer dans le dossier "controllers/front"

une fois ce nouveau fichier créer il le remplir comme cela :

<?php
/*
 * 2007-2015 PrestaShop
 *
 * NOTICE OF LICENSE
 *
 * This source file is subject to the Academic Free License (AFL 3.0)
 * that is bundled with this package in the file LICENSE.txt.
 * It is also available through the world-wide-web at this URL:
 * http://opensource.org/licenses/afl-3.0.php
 * If you did not receive a copy of the license and are unable to
 * obtain it through the world-wide-web, please send an email
 * to [email protected] so we can send you a copy immediately.
 *
 * DISCLAIMER
 *
 * Do not edit or add to this file if you wish to upgrade PrestaShop to newer
 * versions in the future. If you wish to customize PrestaShop for your
 * needs please refer to http://www.prestashop.com for more information.
 *
 *  @author PrestaShop SA <[email protected]>
 *  @copyright  2007-2015 PrestaShop SA
 *  @license    http://opensource.org/licenses/afl-3.0.php  Academic Free License (AFL 3.0)
 *  International Registered Trademark & Property of PrestaShop SA
 */

/**
 * @since 1.5.0
 */
class <Namepaymentmodule>ValidationModuleFrontController extends ModuleFrontController
{
	/**
     * @see FrontController::postProcess()
     */
    public function postProcess()
    {
		//ICI CODE du fichier racine validation.php à mettre
	}
}
?>

A savoir qu'il faut remplacer <NamePaymentModule> par le nom de votre module de paiement auquel il faudra une majuscule à la première lettre. Dans mon cas le nom de mon module s'appelle "clicandpay". Par conséquent ma class s'appellera :

class ClicandpayValidationModuleFrontController extends ModuleFrontController

Le nom de votre module est normalement le nom du dossier racine de votre module de paiement contenu dans le dossier "modules" de prestashop. Sinon vous pouvez voir le nom de votre module dans le fichier à la racine ayant le meme nom que le dossier de votre module de paiement. Dans la méthode construct vous verrez cette ligne la :

$this->name = 'nommodule';

2) Une fois le controller créer il va falloir copier/coller le code du fichier "standalone" de retour de paiement à la racine de votre module à l'intérieur de celui-ci. Il faudra globalement tout copié sauf si vous avez en début de fichier ces lignes :

require_once dirname(dirname(dirname(__FILE__))).'/config/config.inc.php';
require_once dirname(__FILE__) . '/clicandpay.php';

Par contre les autre require du style "_PS_MODULE_DIR_" doivent être présent :

require_once _PS_MODULE_DIR_.'clicandpay/classes/ClicandpayResponse.php';

Pour vous aider je vous est mis en PJ du post mon fichier FrontController qui se nomme "validation.php" et l'ancien système de validation se nommant "validation-old.php"

3) Le Front controller est créé, il faut maintenant le déclarer dans le constructeur du module de paiement. C'est un fichier portant le meme nom que le nom de votre module et qui est à la racinne de votre module de paiment. Dans mon cas :

Dans ce fichier pour déclarer votre nouveau frontcontroller il faut l'ajouter dans la liste des controllers de la méthode "construct". Par exemple dans mon cas je suis passer de :

$this->controllers = array('redirect', 'submit', 'rest', 'iframe');

a :

$this->controllers = array('redirect', 'submit', 'rest', 'iframe', 'validation');

A noter que c'est le nom du fichier et nom la dénomination de la classe qu'il faut mettre.

4) Maintenant il va falloir permettre l'accès à ce controller par votre banque. Pour cela il faut connaitre l'url d'accès de votre nouveau frontcontroller. Le plus simple est de ne pas prendre la forme d'url rewritting mais de la prendre sous forme but.

Ainsi un front controller s'appelle de cette manière :

http://your-url.domain/index.php?fc=module&module=<name-of-your-module>&controller=<name-of-your-controller>

Dans mon cas je remplace :

<name-of-your-module> = clicandpay

<name-of-your-controller> = validation

5) Dernière étape il faut maintenant aller dans le back-office Marchand de votre banque affilié à votre boutique ou vous pouvez gérer les paiement/historique/etc...

Dans ce backoffice il faut que vous repériez la gestion des règle de notifications. Et dans cette page il faut éditer "l'url de notification à la fin du paiement" pour y mettre la nouvelle URL de votre FrontController.

Dans mon cas :

Comme vous le voyez j'ai un mode TEST et un mode PRODUCTION. Vous pouvez donc dans un premier temps uniquement modifier l'url en mode TEST, faire vos test et ensuite apres le répercuter sur le mode PRODUCTION.

De plus le nouveau FrontController que vous avez créer dans votre module de paiement doit avoir les bon droit d'accès pour que la banque puisse avoir accès à l'appel de celui-ci. Si mes souvenirs sont bon les fichier prestashop doivent avoir le droit d'écriture 644.

6) Et voilà normalement vous pouvez procéder à des paiement de test et ca devrait fonctionner comme ca fonctionne chez moi.

J'espère que j'ai été clair et n'hésitez pas à dire ce qui ne l'est pas.

validation.php

validation-old.php

Edited July 30, 2019 by c00lsp0t (see edit history)

flyman30 · July 30, 2019

Beau boulot !

Je ne suis pas capable de faire ça le module que nous employons e-transaction n'a pas la même configuration, mais j'ai transmis à e-transaction ta méthode en espérant que ça fasse avancer un mise à jour du module.

ttoine · July 30, 2019

Si besoin, ils peuvent nous contacter, nous sommes facile à joindre. On pourra certainement les aider s'ils n'y arrivent pas.

flyman30 · July 30, 2019

il y a une heure, ttoine a dit :

Si besoin, ils peuvent nous contacter, nous sommes facile à joindre. On pourra certainement les aider s'ils n'y arrivent pas.

Merci ttoine pouvez-vous m'indiquer le moyen de vous joindre en MP si vous préférez.

Cordialement

Edited July 30, 2019 by flyman30 (see edit history)

LaurentDP · July 30, 2019

2 hours ago, flyman30 said:

Beau boulot !

Je ne suis pas capable de faire ça le module que nous employons e-transaction n'a pas la même configuration, mais j'ai transmis à e-transaction ta méthode en espérant que ça fasse avancer un mise à jour du module.

Idem, e-transaction du credit agricole et impatient de voir la finalité ^^

c00lsp0t · July 30, 2019

Apres si vous avez le module de paiement e-transaction en zip je peut voir si je peut faire quelquechose même si j'ai pas moyen de test. Peut etre que.

flyman30 · July 31, 2019

Il y a 9 heures, c00lsp0t a dit :

Apres si vous avez le module de paiement e-transaction en zip je peut voir si je peut faire quelquechose même si j'ai pas moyen de test. Peut etre que.

Lors de l'installation le module s'installe en mode test

prestashop-1.5.x-1.6.x-1.7.x-etransactions-3.0.12 (1).zip

ttoine · July 31, 2019

il faudra pouvoir tester pour de vrai, avec une carte bleue, c'est le plus sûr.

Soyons Solidaire · July 31, 2019

Vous voulez mon numero compte 😁

c00lsp0t · July 31, 2019

Pour ceux utilisant le module CMCICMONETICO (version 3.0.4) paiement pour la version 1.7 de prestashop en aidant une personne à mettre en place un correctif j'ai produit un zip de patch.

Normalement le patch est ok et testé par une personne qui utilise ce moyen de paiement.

Si vous avez de quoi contacter les développeurs et leur proposer la chose le zip est en PJ.

cmcicpaiement.zip

Edited July 31, 2019 by c00lsp0t (see edit history)

c00lsp0t · July 31, 2019

Concernant e-transaction bon pour l'instant en effet la structure est différente donc j'ai pas encore d'idée corrective. A creuser donc.

Webmain · July 31, 2019

En tout cas module parfaitement patch avec ce zip.

Merci beaucoup.

c00lsp0t · July 31, 2019

Ok cool les module de Lyra Network ont été mis à jour. Ils ont été réactif :

https://github.com/lyra/plugin-prestashop/releases

Ca comprend ces moyens de paiement :

BNPP_IRB_PrestaShop_1.5-1.7_v1.11.2.zip945 KB

ClicAndPay_By_groupe_Credit_du_Nord_PrestaShop_1.5-1.7_v1.11.2.zip1.37 MB

Cobro_Inmediato_PrestaShop_1.5-1.7_v1.11.2.zip1.15 MB

Lyra_PrestaShop_1.5-1.7_v1.11.2.zip1.11 MB

PayZen_IN_PrestaShop_1.5-1.7_v1.11.2.zip784 KB

PayZen_LAT_PrestaShop_1.5-1.7_v1.11.2.zip1.16 MB

PayZen_PrestaShop_1.5-1.7_v1.11.2.zip1.43 MB

Sogecommerce_PrestaShop_1.5-1.7_v1.11.2.zip1.35 MB

Systempay_PrestaShop_1.5-1.7_v1.11.2.zip

Et le changelog :

This release is compatible with Prestashop 1.5, 1.6 and 1.7 versions. It requires PHP 5.3 or higher.

Changes in this version :

Bug fix: JavaScript loaded but not executed in iframe mode (on some PrestaShop 1.7 themes).
Bug fix: Minimum and maximum amounts are not considered if equal to zero in customer group amount restriction.
Compatibility with PrestaShop 1.7.6 (fix fatal error on IPN call).
Possibility to disable payment result display on order details using a flag within payzen.php file (on PrestaShop > 1.7.1.1).

flyman30 · July 31, 2019

il y a une heure, c00lsp0t a dit :

Concernant e-transaction bon pour l'instant en effet la structure est différente donc j'ai pas encore d'idée corrective. A creuser donc.

Pas de chance pour moi, neanmoins les dev de ce module e-transaction sont en train de s'en occuper avec l'aide des dev de Prestashop, combien de temps ça prendra ça reste un mystère.

ttoine · August 1, 2019

Dernière news: CIC payment devrait être dispo aujourd'hui, peut-être même ce matin

Je vous tiens au courant quand j'ai les infos pour les autres.

merci à @c00lsp0t pour l'info à propos des modules de Lyra Networks

c00lsp0t · August 1, 2019

28 minutes ago, ttoine said:

Dernière news: CIC payment devrait être dispo aujourd'hui, peut-être même ce matin

Je vous tiens au courant quand j'ai les infos pour les autres.

merci à @c00lsp0t pour l'info à propos des modules de Lyra Networks

J'ai regarde leur correctif pour mon module clicandpay et il se sont pas emmerdé. Ils ont conservé leur fichier validation.php comme fichier "standalone". Ils ont simplement fait un rebuild du context dans le fichier pour en faire un FrontController

/* rebuild context */
$controller = new FrontController();
$controller->init();

Context::getContext()->controller = $controller;

Personnellement je trouve ca un peu crade mais bon ca fonctionne.

Edited August 1, 2019 by c00lsp0t (see edit history)

jojocarofr · August 2, 2019

Hello a tous

J'ai le problème suivant , un client fait une commande paiement paypal ou systempay

Les 2 paiements sont acceptés en backoffice , mais le client n'a pas les mails de confirmations

Erreur 500 de systempay version 1.11.2

Paypal: Order validation error : Price specification not found for currency: ""

Hors dans la base ps_currency est nickel à 2

Que faire

Merci de vos aides

Suite mise à jour 1.7.5.2 -> 1.7.6.0 les retours bancaire ne se font pas !

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment