Prestashop: Bank payment modules are in error with version 1.7.6.0

Created on 15 Jul 2019  ·  59Comments  ·  Source: PrestaShop/PrestaShop

Hello, I was in
Prestashop version 1.7.5.2
Debian Server 3.16.51-3
Apache
Php 5.6.36
MySql 10.0.32-MariaDB-0 + deb8u1
E-transaction payment module

Update to 1.7.6.0 successful but the card payment module An error appears when trying to pay:

https://tpeweb.e-transactions.fr/cgi/MYchoix_pagepaiement.cgi
Protection error.
We regret not being able to give a favorable answer to your request for payment.

Back to PrestaShop 1.7.5.2 and there the module works!
For info on the French forum of PrestShop another member with a similar problem:
For information, I have a similar concern with the payment module systemPay.

I have a 500 error calling the notification url

1.7.6.0 Bug FO Major No change required Payment
Source
picture flyman30

Most helpful comment

That would mean that virtually ALL bank payment modules are obsolete because they would no longer meet the standards imposed by PrestaShop ???

No, just the ones that don't follow PrestaShop recommendations. Modules bypassing PrestaShop were working by chance and chance alone until now, it was just a matter of time.

So i missed something to create validation front controller ?

Did you check that the URL of your controller is correct and reachable?

BO site module payment need access URL file php for construct notification URL.

I'm not sure what you meant here but if the payment processor absolutely needs the endpoint to be named "validation.php" you could keep the file and issue a http 301 permanent redirect to the controller URL.

only because prestashop don't want use "bad practice" anymore.

This is not true. The process seems to be failing because the dependency container is not initialized when you don't go through a Controller. Until now, it just happened to work fine by chance, because the DC wasn't being used in that specific flow. It was just a matter of time, now it's needed because the new currency handling system uses it.

We cannot take any responsibility when people don't follow PS recommandations.

Also, did you perchance test your module when we asked module developers to test them with 1.7.6 beta back in May?

picture eternoendless on 29 Jul 2019
❤7

All 59 comments

Hi @flyman30,

Could you please provide us with more info? We need more details to understand how we can reproduce your issue:

  • host
  • server setup and configuration
  • PrestaShop version (source)
  • debug mode report
  • PHP error logs
  • apache error log
  • javascript console log
  • screenshots

Don't you know how to get this information? Please read the following article:
http://build.prestashop.com/howtos/misc/how-to-create-bug-report/

Thanks!

mariem-abid picture mariem-abid on 15 Jul 2019

Host: Ikoula.fr
URL test site: http://116044hpv114002.ikexpress.com
Prestashop 1.7.6.0
Debian Server 3.16.51-3
Apache
Php 7.1.17
MySql 10.0.32-MariaDB-0 + deb8u1
E-transaction payment module

the currency is missing in the basket data transmission

De : mariem-abid notifications@github.com
Envoyé : lundi 15 juillet 2019 15:49
À : PrestaShop/PrestaShop PrestaShop@noreply.github.com
Cc : flyman30 flyman30@live.fr; Mention mention@noreply.github.com
Objet : Re: [PrestaShop/PrestaShop] Bank payment modules are in error with version 1.7.6.0 (#14648)

Hi @flyman30https://github.com/flyman30,

Could you please provide us with more info? We need more details to understand how we can reproduce your issue:

  • host
  • server setup and configuration
  • PrestaShop version (source)
  • debug mode report
  • PHP error logs
  • apache error log
  • javascript console log
  • screenshots

Don't you know how to get this information? Please read the following article:
http://build.prestashop.com/howtos/misc/how-to-create-bug-report/

Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/PrestaShop/PrestaShop/issues/14648?email_source=notifications&email_token=ACYCDLAFJVYHK5IHB6KIG6DP7R55FA5CNFSM4IDUM7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ5X4TA#issuecomment-511409740, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACYCDLDZ6JQMDHAADD5CFGLP7R55FANCNFSM4IDUM7XQ.

flyman30 picture flyman30 on 15 Jul 2019

Hi @flyman30,

In your shop, I did not manage to reproduce the issue using "Payer par chèque".
https://drive.google.com/file/d/1TtGjTaBz8zRAlsmzPpH_WFPedVv0xLUn/view
About the other payment modules, have you tried to contact the module's author about this issue, if you need an update for those modules for the new release PS1.7.6.0?

Thanks to check with them & feedback.

khouloudbelguith picture khouloudbelguith on 16 Jul 2019

Yes I joined the provider of the payment module by credit card, we found that if we do a new installation of a shop in 1.7.6.0, the banking module works!
On the other hand by updating version 1.7.5.2 -> 1.7.6.0 the module displays the security error (in fact PBX_DEVISE: 0 is zero in the transmission of the basket)

De : khouloudbelguith notifications@github.com
Envoyé : mardi 16 juillet 2019 10:19
À : PrestaShop/PrestaShop PrestaShop@noreply.github.com
Cc : flyman30 flyman30@live.fr; Mention mention@noreply.github.com
Objet : Re: [PrestaShop/PrestaShop] Bank payment modules are in error with version 1.7.6.0 (#14648)

Hi @flyman30https://github.com/flyman30,

In your shop, I did not manage to reproduce the issue using "Payer par chèque".
https://drive.google.com/file/d/1TtGjTaBz8zRAlsmzPpH_WFPedVv0xLUn/view
About the other payment modules, have you tried to contact the module's author about this issue, if you need an update for those modules for the new release PS1.7.6.0?

Thanks to check with them & feedback.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/PrestaShop/PrestaShop/issues/14648?email_source=notifications&email_token=ACYCDLBK44D76H3LMRUSALTP7WAATA5CNFSM4IDUM7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2ACUPI#issuecomment-511715901, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACYCDLCFBEMEXZVTBVZBSOTP7WAATANCNFSM4IDUM7XQ.

flyman30 picture flyman30 on 16 Jul 2019

In debug mode i have this,

`[PrestaShopDatabaseException]
Table 'boutique.ps_aninstagram' doesn't exist

SELECT m.id_insta, m.position
FROM ps_aninstagram m
WHERE m.id_shop = 1
AND active = 1
AND m.id_shop = 1
GROUP BY m.id_insta

at line 769 in file classes/db/Db.php

  1. if ($webservice_call && $errno) {
  2. $dbg = debug_backtrace();
  3. WebserviceRequest::getInstance()->setError(500, '[SQL Error] ' . $this->getMsgError() . '. From ' . (isset($dbg[3]['class']) ? $dbg[3]['class'] : '') . '->' . $dbg[3]['function'] . '() Query was : ' . $sql, 97);
  4. } elseif (_PS_DEBUG_SQL_ && $errno && !defined('PS_INSTALLATION_IN_PROGRESS')) {
  5. if ($sql) {
  6. throw new PrestaShopDatabaseException($this->getMsgError() . '

    ' . $sql . '
    ');
  7. }


    1. throw new PrestaShopDatabaseException($this->getMsgError());

  9. }
  10. }
    DbCore->displayError - [line 385 - classes/db/Db.php] - [1 Arguments]
    DbCore->query - [line 613 - classes/db/Db.php] - [1 Arguments]
    DbCore->executeS - [line 202 - modules/aninstagramfeed/classes/insta.php] - [2 Arguments]
    Insta::getHooks - [line 464 - modules/aninstagramfeed/aninstagramfeed.php]
    Aninstagramfeed->__call - [line 970 - classes/Hook.php] - [2 Arguments]
    HookCore::coreCallHook - [line 355 - classes/Hook.php] - [3 Arguments]
    HookCore::callHookOn - [line 907 - classes/Hook.php] - [3 Arguments]`
flyman30 picture flyman30 on 16 Jul 2019

@flyman30, this issue occurs due to the aninstagramfeed module.
Have you tried to contact the module author about this issue?

Thanks!

khouloudbelguith picture khouloudbelguith on 16 Jul 2019

The original issue may be related to https://github.com/PrestaShop/PrestaShop/issues/14608.

When we upgrade to 1.7.6.0, prices are displayed with 6 decimals, which could explain why payment modules can't work after an upgrade.

Quetzacoalt91 picture Quetzacoalt91 on 16 Jul 2019
👍1

hi ,

we have similar issues with bank modules, the error is :

stderr: thrown in public_html/classes/Tools.php on line 801 stderr: #3 {main} stderr: #2 modules/XXXX/validation.php(123) PaymentModule->validateOrder stderr: #0 classes/Tools.php(773): ToolsCore::getContextLocale(Object(Context)) stderr: PHP message: PHP Fatal error: Uncaught Error: Call to a member function get() on null in classes/Tools.php:801

this seem due to modules using /module/Mybank/valdation.php to notifiy the transactions , whithout a clean front controller there is no controller on : https://github.com/PrestaShop/PrestaShop/blob/1.7.6.x/classes/Tools.php#L801

$container = isset($context->controller) ? $context->controller->getContainer() : null;
        if (null === $container) {
            $container = SymfonyContainer::getInstance();
        }
        /** @var LocaleRepository $localeRepository */
        $localeRepository = $container->get(self::SERVICE_LOCALE_REPOSITORY);
        $locale = $localeRepository->getLocale(
            $context->language->getLocale()
        );`

i does not know if the core prestashop has to correct this or modules editors ?

regards

123monsite-regis picture 123monsite-regis on 23 Jul 2019

Pending the correction of the future 1.7.6.1 how do we sell?
Do you have any corrections that we could make on our shop that were in 1.7.5.2 update in 1.7.6.0? The corrections of the ps_currency table have solved a small part of the problem, when did the correction of the non-validation in prestashop of the bank's returns?

flyman30 picture flyman30 on 23 Jul 2019

@123monsite-regis, in your Database, table ps_currency, thanks to change the precision from 6 to 2.
Thanks to check & feedback.

khouloudbelguith picture khouloudbelguith on 23 Jul 2019

Bonjour
Le meme bug avec systempay , j'ai fait les modifs sur ps_currency et ca ne fonctionne pas j'ai une erreur lors de la validation de l'achat
Merci de vos aides

jojocarofr picture jojocarofr on 23 Jul 2019

We talk about it here
https://www.prestashop.com/forums/topic/997100-validation-commande-impossible-avec-e-transaction-paybox/

And here
https://www.prestashop.com/forums/topic/997001-suite-mise-%C3%A0-jour-1752-1760-les-retours-bancaire-ne-se-font-pas/?tab=comments#comment-3138331

flyman30 picture flyman30 on 24 Jul 2019

Hi @flyman30, @jojocarofr,

Could you please try to check if you have the same issue with PS1.7.6.0 fresh install?

Thanks!

khouloudbelguith picture khouloudbelguith on 24 Jul 2019

J'utilise le module E-transaction 3.0.12 fournit par ma banque depuis que j'ai une boutique Prestashop (1.7.0.1) sans aucun soucis.
Ce n'est pas le module qui est en cause puisque TOUS les modules de paiement bancaire semble impactés !

  • E-Transaction
  • cmcicpaiement
  • Sogenactif 2.0
  • clicandpay
    etc...

Il faut comprendre pourquoi cette version PrestaShop présente un bug majeur dans la réception des validations bancaire

exemple :
https://www.prestashop.com/forums/topic/997100-validation-commande-impossible-avec-e-transaction-paybox/
https://www.prestashop.com/forums/topic/997001-suite-mise-%C3%A0-jour-1752-1760-les-retours-bancaire-ne-se-font-pas/?tab=comments#comment-3138391

flyman30 picture flyman30 on 24 Jul 2019

Voila les log de PayBox pour un essai de transaction par E-transaction

Voici les logs du retour IPN de votre transaction :

Jul 22 11:00:01 pbxprwb24 PayboxIPN.cgi[63522]: (INF) - Contact de l'URL en POST : https://.com/modules/etransactions/index.php?t=s&a=i - Donnees : M=1710&R
=1190%20-%20patrick%20Planul&T=524982735&A=446555&B=0&C=Visa&D=2106&E=00000&F=Y&G=O&I=FRA&J=--&N=------&O=Y&P=3DSECURE&Q=10%3A59%3A17&S=114349215&W=22072019&Y=FRA&Z=0-0&K=u
X9XAj%2F6sRLy6n1p3WEHKfLIUlsorlkcq6Lygs8f7y1WHaADP3T5DFf59H%2BeX0mRecz1RDRtMXiYN5jF2zykTE4o40hjgzbsbuz1w3LsaDwwnUUWh4jgtG4dkdIB7LA1zdhwpUAQLDz9bFYj5FpZXgY5JC0lU6n2%2BySOXYy
Nup4%3D
Jul 22 11:00:01 pbxprwb24 PayboxIPN.cgi[63522]: (INF) - Resolution DNS IPV4
Jul 22 11:00:01 pbxprwb24 PayboxIPN.cgi[63522]: (INF) - Utilisation de la version SSL par défaut
Jul 22 11:00:01 pbxprwb24 PayboxIPN.cgi[63522]: (INF) - Liste des ciphers SSL forces : RC4-MD5:RC4-SHA:DHE-RSA-AES256-SHA:DES-CBC3-SHA:AES128-SHA:DHE-RSA-AES128-SHA:ECDHE-R
SA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:
ECDHE-RSA-AES128-GCM-SHA256:+ALL
Jul 22 11:00:01 pbxprwb24 PayboxIPN.cgi[63522]: (INF) - Utilisation de libcurl v7.53.1
Jul 22 11:00:11 pbxprwb24 PayboxIPN.cgi[63522]: (ERR) - Erreur de connexion - essai 1 : (code http: 500 - code curl: 0)
Jul 22 11:00:21 pbxprwb24 PayboxIPN.cgi[63522]: (INF) - https://*.com/modules/etransactions/index.php?t=s&a=i - Succes

flyman30 picture flyman30 on 24 Jul 2019

Hi @flyman30,

In my case I tried with those modules:

  • ps_wirepayment
  • ps_checkpayment
  • COD
  • PayPal

They are ok, there is no issue reproduced.

Thanks!

khouloudbelguith picture khouloudbelguith on 24 Jul 2019

cmcicpaiement
Sogenactif 2.0
E-Transaction
clicandpay

Send validation data but it is not validated by Prestashop 1.7.6.0 !

Here is the e-transaction module for test

prestashop-1.5.x-1.6.x-1.7.x-etransactions-3.0.12.zip

flyman30 picture flyman30 on 24 Jul 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

| 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. | 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. | $logger->logInfo("Payment accepted for cart #$cart_id. New order state is $new_state."); $order = $clicandpay->saveOrder($cart, $new_state, $response); | $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;
-- | -- | -- | -- | --
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.
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.
$logger->logInfo("Payment accepted for cart #$cart_id. New order state is $new_state."); $order = $clicandpay->saveOrder($cart, $new_state, $response);
$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;

flyman30 picture flyman30 on 24 Jul 2019

@flyman30, I tried with your module & PS1.7.6.0 & PS1.7.5.2, in the FO => OK
https://drive.google.com/file/d/16w2ocol3AiSujkhA7z42SnS2CfIIuLvt/view & the email is sent => but in the back office there is no order created

Thanks!

khouloudbelguith picture khouloudbelguith on 24 Jul 2019

184/5000
I am glad that you have tested the e-transaction module, with prestashop 1.7.5.2 the order is validated in BO but not in 1.7.6.0.
What do you think, can you do something?

flyman30 picture flyman30 on 24 Jul 2019

I come a little check the log:

In prestashop 1.7.5 the log of a successful payment is like this

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.
While a payment in 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.

Clearly there is a problem in the order creation process in the BO after the payment of the basket.

When I go to the validation.php file of my module I have this function which corresponds to my log entries

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

$order = $clicandpay->saveOrder($cart, $new_state, $response);
And after that, more than OK. It is in the backup creation that there is a bp since 1.7.6.

When I go on the saveOrder method of my module I

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

So the first log message is called in my log but not the following $ this-> validateOrder.

To know that this validateOrder method corresponds to the parent abstract class that my module extends and which is "/classes/PaymentModule.php

I think the trouble comes from this method since 1.7.6. But I admit that I have no easy way to debug this method

flyman30 picture flyman30 on 24 Jul 2019

@flyman30, with PS1.7.5.2 & PS1.7.6.0, in my case, there is no order created in the BO.
In the error log for PS1.7.6., I only have those errors

[2019-07-24 10:34:52] app.ERROR: Class "AdminLinkWidgetController" not found in controllers/admin [] []
[2019-07-24 10:36:44] app.INFO: Exporting mail with theme modern for language Français (French) [] []
[2019-07-24 10:36:44] app.INFO: Core output folder: /projet/QA/1760fr/mails [] []
[2019-07-24 10:36:44] app.INFO: Modules output folder: /projet/QA/1760fr/modules/ [] []

Thanks!

khouloudbelguith picture khouloudbelguith on 24 Jul 2019

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.

jcpaybox picture jcpaybox on 24 Jul 2019

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!

khouloudbelguith picture khouloudbelguith on 24 Jul 2019

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!

Ok i think it's will be difficult to test without account in clicandpay because this issue told invalid key.

I don't know if it's possible to have demo key api test for this module. This is documentation module : https://clicandpay.groupecdn.fr/doc/fr-FR/

webmastercoolspot picture webmastercoolspot on 24 Jul 2019

Ok i proceed with test key in my shop simulate CB Payment with module clicandpay and activate debug mode.
I have this in my log for complete CB payment transaction. I replace personnal information in few input to xxxxxx for anonimyzing log

`INFO v1.7.6.0 2019/07/25 - 01:24:15: Form data generation for cart #111 with standard submodule.
INFO v1.7.6.0 2019/07/25 - 01:24:15: Data to be sent to payment gateway : Array
(
[signature] => R0f/eFNjTYtH/hQQ0vpmGRCxbWMVMpxHF8Xm1RE7YGQ=
[vads_action_mode] => INTERACTIVE
[vads_amount] => 132900
[vads_available_languages] =>
[vads_capture_delay] =>
[vads_contrib] => PrestaShop_1.5-1.7_1.11.1/1.7.6.0/7.2.19
[vads_ctx_mode] => TEST
[vads_currency] => 978
[vads_cust_address] => xxxxxxxxxxx
[vads_cust_cell_phone] =>
[vads_cust_city] => xxxxxxxx
[vads_cust_country] => FR
[vads_cust_email] => [email protected]
[vads_cust_first_name] => xxxxx
[vads_cust_id] => 1
[vads_cust_last_name] => xxxxxx
[vads_cust_phone] =>
[vads_cust_title] => M
[vads_cust_zip] => xxxxx
[vads_language] => fr
[vads_nb_products] => 1
[vads_order_id] => 111
[vads_order_info] => Paiement par carte bancaire
[vads_page_action] => PAYMENT
[vads_payment_cards] =>
[vads_payment_config] => SINGLE
[vads_return_mode] => GET
[vads_ship_to_city] => xxxxxxx
[vads_ship_to_country] => FR
[vads_ship_to_first_name] => xxxxxx
[vads_ship_to_last_name] => xxxxxx
[vads_ship_to_phone_num] =>
[vads_ship_to_street] => xxxxxxxxxxx
[vads_ship_to_street2] =>
[vads_ship_to_zip] => xxxxx
[vads_shipping_amount] => 0
[vads_shop_name] => Climeurope
[vads_shop_url] => https://www.climeurope.fr
[vads_site_id] => xxxxxxx
[vads_tax_amount] => 22150
[vads_theme_config] =>
[vads_totalamount_vat] => 22150
[vads_trans_date] => 20190724232415
[vads_trans_id] => 050555
[vads_url_return] => https://www.climeurope.fr/module/clicandpay/submit
[vads_validation_mode] =>
[vads_version] => V2
[vads_product_label0] => Bi split Toshiba pour 2 Chambres 2 x SEIYA 1 5Kw
[vads_product_amount0] => 110750
[vads_product_qty0] => 1
[vads_product_ref0] => 265
[vads_product_type0] => FOOD_AND_GROCERY
[vads_product_vat0] => 20.0000
)

INFO v1.7.6.0 2019/07/25 - 01:24:24: Server call process starts for cart #111.
INFO v1.7.6.0 2019/07/25 - 01:24:24: Payment accepted for cart #111. New order state is 2.
INFO v1.7.6.0 2019/07/25 - 01:24:24: Create order for cart #111.
INFO v1.7.6.0 2019/07/25 - 01:24:34: User return to shop process starts for cart #111.
INFO v1.7.6.0 2019/07/25 - 01:24:35: Order already registered for cart #111.
INFO v1.7.6.0 2019/07/25 - 01:24:35: The current state for order corresponding to cart #111 is (0).
WARNING v1.7.6.0 2019/07/25 - 01:24:35: Unknown order state ID (0) for cart #111. Managed by merchant.
INFO v1.7.6.0 2019/07/25 - 01:24:35: Payment success for cart #111. Redirect to success page.`

webmastercoolspot picture webmastercoolspot on 25 Jul 2019

In Back office there are a order create but there are no status and no email sent. I need to put manually change order statut in BO to pass in status "paid"

webmastercoolspot picture webmastercoolspot on 25 Jul 2019

In Back office there are a order create but there are no status and no email sent. I need to put manually change order statut in BO to pass in status "paid"

This is exactly what happens with all bank payment modules ...

flyman30 picture flyman30 on 25 Jul 2019

And now ,
Are the developers going to look at this major bug that is preventing many shops from selling normally?
It's urgent for our image!
We need some help..

flyman30 picture flyman30 on 25 Jul 2019

And now that the findings have been made about this major bug, how do we make it to be considered and corrected?
I do not know where to ask.

Flyman30

De : Adrien notifications@github.com
Envoyé : jeudi 25 juillet 2019 01:50
À : PrestaShop/PrestaShop PrestaShop@noreply.github.com
Cc : flyman30 flyman30@live.fr; Mention mention@noreply.github.com
Objet : Re: [PrestaShop/PrestaShop] Bank payment modules are in error with version 1.7.6.0 (#14648)

In Back office there are a order create but there are no status and no email sent. I need to put manually change order statut in BO to pass in status "paid"

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/PrestaShop/PrestaShop/issues/14648?email_source=notifications&email_token=ACYCDLA2J6NHNEZHPFANIYDQBDTBZA5CNFSM4IDUM7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2X5PHQ#issuecomment-514840478, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACYCDLB2N5R3NTITRMQLDJ3QBDTBZANCNFSM4IDUM7XQ.

flyman30 picture flyman30 on 25 Jul 2019

The redsys free module have this sigue too, have 2 clients whit this

LinkOfLight picture LinkOfLight on 26 Jul 2019

Hi all,

As discussed with @webmastercoolspot, I'm trying to reproduce the issue with clicandpaymodule.
So, I need to discuss with the support team: https://clicandpay.groupecdn.fr/doc/fr-FR/support/
to get an account test for me to reproduce the issue with a key test and account test.

Thanks for your understanding!

khouloudbelguith picture khouloudbelguith on 26 Jul 2019

I thought you understood that ALL payment modules have the same problems ie Prestashop 1.7.6.0 does not understand the return of acceptance of payments that the banks transmit.
It is urgent that the developers look for the cause as soon as possible!

flyman30 picture flyman30 on 26 Jul 2019
👍1

Yes it's not only me and clicandpay

I hope it will be fixed as soon as possible

Thx :)

webmastercoolspot picture webmastercoolspot on 26 Jul 2019
👍1

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.

eternoendless picture eternoendless on 26 Jul 2019
👍2

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.

That would mean that virtually ALL bank payment modules are obsolete because they would no longer meet the standards imposed by PrestaShop ???
Thank you for all the shops impacted by this change, a change whose suppliers of bank payment modules have not been warned!

flyman30 picture flyman30 on 26 Jul 2019

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.

Ok you mean if i create in my module folder a /controllers/front/validation.php and structure like this :

class CbCheckpaymentValidationModuleFrontController extends ModuleFrontController
{
public function postProcess()
{
//Insert code contained in validation.php
}
}

And in code i put all code in validation.php in root of my payment module it will be work with prestashop 1.7.6 ?

How to call this new frontcontroller in payment process ?

webmastercoolspot picture webmastercoolspot on 26 Jul 2019

Is it possible to prestashop to revert back for this to way like prestashop 1.7.5.2 even if it's a wrong method to do validation payment.
That permit to payment module dev to update their addon to new proper methode with FrontController and no impact prestashop user ?

webmastercoolspot picture webmastercoolspot on 26 Jul 2019

Ok i try to create a new controller and i name it validation.php in "mymodule/controllers/front"

I create class : 

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

I put in "..........." code there are in my /mymodule/validation.php

My module name is "clicandpay :
$this->name = 'clicandpay';

After i modify my main class of my module to change this :

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

TO this :

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

Adding my new controller in construct main class.

And after this i try to make a test payment in my shop and i always have same bug (after paiement ok my commande have no status and BO Payment module tell me than i have IPN error (notification url return error)

and my log are same :

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

INFO v1.7.6.0 2019/07/27 - 01:46:58: Server call process starts for cart #116.
INFO v1.7.6.0 2019/07/27 - 01:46:58: Payment accepted for cart #116. New order state is 2.
INFO v1.7.6.0 2019/07/27 - 01:46:58: Create order for cart #116.
INFO v1.7.6.0 2019/07/27 - 01:47:01: User return to shop process starts for cart #116.
INFO v1.7.6.0 2019/07/27 - 01:47:01: Order already registered for cart #116.
INFO v1.7.6.0 2019/07/27 - 01:47:01: The current state for order corresponding to cart #116 is (0).
WARNING v1.7.6.0 2019/07/27 - 01:47:01: Unknown order state ID (0) for cart #116. Managed by merchant.
INFO v1.7.6.0 2019/07/27 - 01:47:01: Payment success for cart #116. Redirect to success page.

And in my BO payment module i have error 500 notification URL and message are :

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

So i missed something to create validation front controller ?

Or maybe it's not only the problem.

webmastercoolspot picture webmastercoolspot on 27 Jul 2019

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

Furtheremore. For my payment module it's impossible to not used validation.php in root module.
Indeed, this file is needed in BO payment Module site for to check URL Notification when user put bank card information.

BO site module payment need access URL file php for construct notification URL. If you say that prestashop now need to have only frontcontroller, my payment module will be don't work anymore for prestashop 1.7.6 and more forever
rule-BO-notification

It's not possible for BO module payment to have access url for "ModuleFrontController" prestashop

Because i think module payment won't rework is Back Office (this BO payment merchant is not only for prestashop but for lot of eshop framework like woocomerce/magento/etc....) only because prestashop don't want use "bad practice" anymore.

Best Regard.

webmastercoolspot picture webmastercoolspot on 27 Jul 2019

With 1.7.6.0 fresh and Payzen:
FastCGI sent in stderr: "PHP message: PHP Fatal error: Call to a member function get() on null in /home/oboutique/www/classes/Tools.php on line 801" while reading response header from upstream, client: 194.50.38.134, server: oboutique.fr, request: "POST /modules/payzen/validation.php HTTP/1.1

In Tools :
$localeRepository = $container->get(self::SERVICE_LOCALE_REPOSITORY);

olecorre picture olecorre on 29 Jul 2019

That would mean that virtually ALL bank payment modules are obsolete because they would no longer meet the standards imposed by PrestaShop ???

No, just the ones that don't follow PrestaShop recommendations. Modules bypassing PrestaShop were working by chance and chance alone until now, it was just a matter of time.

So i missed something to create validation front controller ?

Did you check that the URL of your controller is correct and reachable?

BO site module payment need access URL file php for construct notification URL.

I'm not sure what you meant here but if the payment processor absolutely needs the endpoint to be named "validation.php" you could keep the file and issue a http 301 permanent redirect to the controller URL.

only because prestashop don't want use "bad practice" anymore.

This is not true. The process seems to be failing because the dependency container is not initialized when you don't go through a Controller. Until now, it just happened to work fine by chance, because the DC wasn't being used in that specific flow. It was just a matter of time, now it's needed because the new currency handling system uses it.

We cannot take any responsibility when people don't follow PS recommandations.

Also, did you perchance test your module when we asked module developers to test them with 1.7.6 beta back in May?

eternoendless picture eternoendless on 29 Jul 2019
❤7

Again to make things clear: This is not a new recommendation, you should have NEVER bypassed ModuleFrontControllers, which exist since 1.5.0. Your code was working by chance, and it's just now that it has become evident.

eternoendless picture eternoendless on 29 Jul 2019
👍1

With 1.7.6, there has been many Beta and RC releases, in order to test it, but, also, to test modules and report issues. That could have been solved before the release.

I can't see any issue opened on this problem before this one, including on the forum.

For reference on the best practice:
https://devdocs.prestashop.com/1.7/modules/concepts/controllers/front-controllers/#example-of-method-calls

ttoine picture ttoine on 29 Jul 2019

So i missed something to create validation front controller ?

Did you check that the URL of your controller is correct and reachable?

BO site module payment need access URL file php for construct notification URL.

I'm not sure what you meant here but if the payment processor absolutely needs the endpoint to be named "validation.php" you could keep the file and issue a http 301 permanent redirect to the controller URL.

Ok and how i put my controller reachable ?

Did you mean i need to put this to be reachable :
Context::getContext()->link->getModuleLink('clicandpay', 'validation', array()); ?

If yes where to put this code in my module ?

Or just need to redirection 301 old validation.php to my controllers/front/validation.php ?

Sorry for my newbie question i just try to understand.

webmastercoolspot picture webmastercoolspot on 29 Jul 2019

That would mean that virtually ALL bank payment modules are obsolete because they would no longer meet the standards imposed by PrestaShop ???

No, just the ones that don't follow PrestaShop recommendations. Modules bypassing PrestaShop were working by chance and chance alone until now, it was just a matter of time.

So i missed something to create validation front controller ?

Did you check that the URL of your controller is correct and reachable?

BO site module payment need access URL file php for construct notification URL.

I'm not sure what you meant here but if the payment processor absolutely needs the endpoint to be named "validation.php" you could keep the file and issue a http 301 permanent redirect to the controller URL.

only because prestashop don't want use "bad practice" anymore.

This is not true. The process seems to be failing because the dependency container is not initialized when you don't go through a Controller. Until now, it just happened to work fine by chance, because the DC wasn't being used in that specific flow. It was just a matter of time, now it's needed because the new currency handling system uses it.

We cannot take any responsibility when people don't follow PS recommandations.

Also, did you perchance test your module when we asked module developers to test them with 1.7.6 beta back in May?

We have same problem with CM-CIC / Monetico Paiement module

Is it possible to prestashop to revert back for this to way like prestashop 1.7.5.2 even if it's a wrong method to do validation payment.
That permit to payment module dev to update their addon to new proper methode with FrontController and no impact prestashop user ?

I agree webmasercools, may a deprecated method should remain available : many payment modules seems to have same problem

tdf-mep picture tdf-mep on 29 Jul 2019

If this is reverted to the old behavior, be aware that it means that no module, and no dev will make the job to use best practices...
again, that's why beta and release candidate are released: to test and report issues.

ttoine picture ttoine on 29 Jul 2019

Ok and how i put my controller reachable ?

As stated in the documentation, your front controller is accessible in an URL like this:

// if the shop uses friendly urls
http://your-url.domain/<language-code-if-multilanguage>/module/<name-of-your-module>/<name-of-your-controller>

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

Just keep in mind:

  • If your module is called "clicandpay" and your controller is "Validation.php" then the classname should be named "ClicandpayValidationModuleFrontController" (as explained here)
  • In the links above, <name-of-your-controller> should be replaced with "Validation" and not "ClicandpayValidationModuleFrontController"

That is how routing works in PrestaShop.

This code would return that same URL when run in PS:

Context::getContext()->link->getModuleLink('clicandpay', 'validation', array());

You can use this module to see a working example: https://github.com/PrestaShop/ps_buybuttonlite

For the redirection, you can just add a header in your old validation.php so the bank is redirected to the new address (as long as their client follows redirections).

header('Location: '. $theNewAddressExplainedAbove, true, 301);

may a deprecated method should remain available : many payment modules seems to have same problem

The deprecated method Tools::displayPrice() is still available and widely used. But it has to be run in a PrestaShop context (aka through a PrestaShop route) and won't work properly otherwise, because it needs the Dependency Container to be initialized. You can still initialise the DC by yourself if you insist, I've seen some workarounds, but I strongly discourage you from doing that, and if you decide to go that way you're on your own. Either way it's much, much easier, more stable and more secure just to go through a controller or redirect to a controller.

This is also why we removed or deprecated most of our old endpoints in 1.7.6.

Once more: I strongly suggest AGAINST including PrestaShop classes on your PHP code, and using them statically. Chances are that they won't work on their own, and even if they do _today_, there's no assurance that they will tomorrow.

Static methods are evil because they rely on global state and are based on assumptions. This is a perfect example of why it's so bad. And that's why we need to get rid of them.

eternoendless picture eternoendless on 29 Jul 2019

Oh and also: this cannot and will not be reverted because the new currency system is based on multiple independent services which are managed through the Dependency Container. Separate systems are easier to develop, maintain and test.

I'm sorry that your modules stopped working but this is due to bad practices in the past that allowed some things to work in a way that they should never have been allowed to in the first place.

Following good practices is the best way of ensuring this doesn't happen again.

eternoendless picture eternoendless on 29 Jul 2019
❤4 👀1

I have read your previous posts and i understand what you say.

My mistake is a lack of test before upgrading to this version : shame one me for that !!!

But you may understant : I (we ?) are a little bit lost / disappointed.
Unless I'm mistaken on test or anything else :

  • CM-CIC / Monetico Paiement is still sell at 300€
    => tag as compatible 1.7.6.0
    => tag as develop by Prestashop (is it wright ?)
    => (i wrote a message to this module support to explain this problem witout response until now)

So :
=> Prestashop developpers of the module don't follow Prestashop rules ?
=> No one test this module during Beta and RC ? (may unit / integration tests can be implemented ?)
=> Maybe something can be improve in doc to warn about this : many payment module in same situation ?

I'm not a beta-tester and I don't want / hunderstant why should fix that module by myself : I just want my shop to work.

No intention of being aggressive with this post : it's just a complicated situation for many of us without (easy) solution (roll-back to previous prestashop release ?) for a couple of weeks now.

I should not upgrade before well testing, I known...

tdf-mep picture tdf-mep on 29 Jul 2019
👍1

@tdf-mep thank you for your message.
this is great to read an answer like this one.

About your questions: you are right, and we are currently investigating in order to understand why it happened, and what can be done to solve the issue quickly.

BTW, it is quite amazing that only french banks modules have an issue.

ttoine picture ttoine on 29 Jul 2019

Ok With suggestion of @eternoendless i made my payment module work again . Thanks to you

My new 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.`

All is good because in return BO i have a status for my commande (PJ)

ok-paiement

I will try to make full tutorial for help other marchand have problem here : https://www.prestashop.com/forums/topic/997001-suite-mise-%C3%A0-jour-1752-1760-les-retours-bancaire-ne-se-font-pas/

Thanks agains to @eternoendless for his suggestion :)

webmastercoolspot picture webmastercoolspot on 30 Jul 2019
👍4 🎉1

Hi @webmastercoolspot

I'm glad that my suggestion worked :)

Now that the problem and its solution have been identified, I'm closing this issue.

eternoendless picture eternoendless on 30 Jul 2019

Please don't close this issue, others payment modules are involved

jf-viguier picture jf-viguier on 30 Jul 2019

Redsys is broken

Angel Moreno Cubero - Administrador de Tech4Life - www.tech4life.eshttp://www.tech4life.es
Advertencia Legal: La información que contiene este correo electrónico y, en su caso, los ficheros adjuntos, está dirigida a la persona cuya dirección electrónica figura en la cabecera. Si usted recibe este correo electrónico y no es el destinatario, ruegolo borre de inmediato y comunique dicha circunstancia. Cualquier uso fraudulento realizado con el contenido del correo electrónico recibido queda sometido a las acciones previstas por la legislación vigente. Queda expresamente prohibida la divulgación, copia o distribución a terceros sin la previa autorización.
Política de Protección de Datos de Carácter Personal:En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre, sobre Protección de Datos de Carácter Personal (LOPD), y el propio Reglamento General de Protección de Datos, ANGEL MORENO CUBERO,Responsable del Fichero, informa a los usuarios que los Datos de Carácter Personal que recoge son objeto de tratamiento mixto, y se incorporan en los ficheros correspondientes debidamente registrados en la Agencia Española de Protección de Datos. En nombre de la empresatratamos la información que nos facilita con el fin de prestarles el servicio solicitado y realizar la facturación del mismo. Los datos proporcionados se conservarán mientras se mantenga la relación comercial o durante los años necesarios para cumplir con las obligaciones legales. Los datos no se cederán a terceros salvo en los casos en que exista una obligación legal. En virtud de lo establecido en la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y de Comercio Electrónico (LSSI-CE), ANGEL MORENO CUBERO, Responsable del Fichero, le informa que podrá utilizar las direcciones de correo electrónico facilitadas por los usuarios, para mantenerles informado acerca de lo concerniente a la relación comercial establecida. Usted da su consentimientoexpreso para que el Responsable del Fichero, ANGEL MORENO CUBERO, pueda utilizar su dirección de correo electrónico con este fin concreto Usted tiene derecho a obtener confirmación sobre si ANGEL MORENO CUBERO está tratando sus datos personales, por tanto tiene derecho a acceder a sus datos personales, rectificar los datos inexactos o solicitar su supresión cuando los datos ya no sean necesarios. En ningún caso le será enviada publicidad de ningún tipo. El usuario podrá en todo momento ejercitar los referidos derechos reconocidos en la LOPD, de Acceso, Rectificación, Cancelación y Oposición (ARCO). El ejercicio de estos derechos puede realizarlo el propio usuario acompañando copia del DNI de manera presencial en las oficinas de ANGEL MORENO CUBERO, titular del DNI 26820694A, como Responsable del Fichero, bien mediante correo electrónico [email protected], o bien mediante comunicación escrita a la siguiente dirección postal Ángel Moreno Cubero. C/ Juan Ramón Jiménez 1 Local- Doña Mencía (Córdoba). C.P. 14860 – España.

De: Jean-François Viguier notifications@github.com
Enviado: Tuesday, July 30, 2019 11:48:59 AM
Para: PrestaShop/PrestaShop PrestaShop@noreply.github.com
Cc: LinkOfLight angel-moreno-cubero@outlook.com; Comment comment@noreply.github.com
Asunto: Re: [PrestaShop/PrestaShop] Bank payment modules are in error with version 1.7.6.0 (#14648)

Please don't close this issue, others payment modules are involved

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPrestaShop%2FPrestaShop%2Fissues%2F14648%3Femail_source%3Dnotifications%26email_token%3DACF5JTEXL6KKTZCYGQFUPXTQCAFAXA5CNFSM4IDUM7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3DNZLA%23issuecomment-516349100&data=02%7C01%7C%7Cdc710529d8ae4a25ce6a08d714d325f0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637000769407454570&sdata=jNJUmzXs3GFpUXZ7osID6iUUtm83B7AP7F0wm484siE%3D&reserved=0, or mute the threadhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACF5JTD7TYZLI4Y6O2YFWA3QCAFAXANCNFSM4IDUM7XQ&data=02%7C01%7C%7Cdc710529d8ae4a25ce6a08d714d325f0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637000769407464581&sdata=ZaGmOYcmGTJ6pX%2Bg5ik2uT1NLlSoxpucpmP1gci8mb8%3D&reserved=0.

LinkOfLight picture LinkOfLight on 30 Jul 2019

Please don't close this issue, others payment modules are involved

To my best understanding this is a module issue, and not an issue with PrestaShop itself that can be fixed in the Core. As such, there's nothing we can do, it has to be addressed by their respective developers using the solution explained above.

If more information is found that could point to a problem within PrestaShop, feel free to open a new issue.

Modules developed by PrestaShop that present this issue are being fixed by the appropriate team as we speak. For modules developed by other vendors, you will have to get in touch with them and ask them to make sure their modules are compatible with PrestaShop 1.7.6.

eternoendless picture eternoendless on 30 Jul 2019

If you are understand french. I've made a post of my modification. Maybe it help : https://www.prestashop.com/forums/topic/997001-suite-mise-%C3%A0-jour-1752-1760-les-retours-bancaire-ne-se-font-pas/?tab=comments#comment-3140082

Sorry not enought good in english for do same in english

webmastercoolspot picture webmastercoolspot on 30 Jul 2019
👍2

The modified e-transaction module for PrestaShop 1.7.6. * To PrestaShop standards has arrived, tested and functional.

If you want it, ask me i will sent it ZIP files.

flyman30 picture flyman30 on 11 Oct 2019
👍2

Hi, official releases for paybox and e-transactions are coming shortly, we will push them asap to github.

feel free to contact us for any further information: [email protected]

jcpaybox picture jcpaybox on 11 Oct 2019
👍2
Was this page helpful?
0 / 5 - 0 ratings

Related issues

sandra2n picture sandra2n  ·  3Comments
matks picture matks  ·  3Comments
centoasa picture centoasa  ·  3Comments
hiousi picture hiousi  ·  3Comments
rGaillard picture rGaillard  ·  3Comments