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

July 22

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...

July 22

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

July 22

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.

July 22

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

July 23

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

July 23

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é.

July 23

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:

July 23

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 by c00lsp0t (see edit history)

July 23

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)

July 24

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 ???

July 24

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

July 24

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.

July 24

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 by c00lsp0t (see edit history)

July 24

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.

July 24

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 by c00lsp0t (see edit history)

July 24

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.

July 24

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 !!!

July 24

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 by flyman30 (see edit history)

July 24

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.

July 24

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);

July 24

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

July 24

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

July 24

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

July 24

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 ?

July 24

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

July 24

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

July 24

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

July 24

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 by c00lsp0t (see edit history)

July 24

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 !

July 24

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

July 24

Ç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!

July 24

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 !!

July 24

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é.

July 24

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

July 24

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

July 24

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.

July 24

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 by flyman30 (see edit history)

July 24

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 by c00lsp0t (see edit history)

July 25

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

July 25

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 by tdf-mep (see edit history)

July 25

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)

July 25

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 by c00lsp0t (see edit history)

July 25

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).

July 25

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é.

July 25

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

July 25

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

July 25

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 )

July 26

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.

July 26

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 by c00lsp0t (see edit history)

July 26

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.

July 26

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 <contact@prestashop.com>
 * @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 by tdf-mep (see edit history)

July 26

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"

July 26

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 by c00lsp0t (see edit history)

July 27

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.

July 27

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)

July 27

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 by tdf-mep (see edit history)

July 27

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

July 27

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 by c00lsp0t (see edit history)

July 27

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) .

July 27

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 !!!!

July 27

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 by TCHOUPI (see edit history)

July 27

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

July 27

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 by c00lsp0t (see edit history)

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

Recommended Posts

flyman30 24

Share this post

Link to post

Share on other sites

tdf-mep 3

Share this post

Link to post

Share on other sites

flyman30 24

Share this post

Link to post

Share on other sites

flyman30 24

Share this post

Link to post

Share on other sites

tdf-mep 3

Share this post

Link to post

Share on other sites

digeek 0

Share this post

Link to post

Share on other sites

SuperPseudo1234 0

Share this post

Link to post

Share on other sites

c00lsp0t 8

Share this post

Link to post

Share on other sites

c00lsp0t 8

Share this post

Link to post

Share on other sites

flyman30 24

Share this post

Link to post

Share on other sites

digeek 0

Share this post

Link to post

Share on other sites

flyman30 24

Share this post

Link to post

Share on other sites

c00lsp0t 8

Share this post

Link to post

Share on other sites

Howie 0

Share this post

Link to post

Share on other sites

c00lsp0t 8

Share this post

Link to post

Share on other sites

flyman30 24

Share this post

Link to post

Share on other sites

flyman30 24

Share this post

Link to post

Share on other sites

flyman30 24

Share this post

Link to post

Share on other sites

c00lsp0t 8

Share this post

Link to post

Share on other sites

digeek 0

Share this post