Hello, and thanks a lot for your efforts in developing such a module !
I can only see RC branches of your module here in github... isn't there any Stable release ?

thanks you very much

Hello,

J'ai essayé d'installer le module ( RC 3.0.0 et developpement) sur Prestashop 1.5.4. L'installation se passe sans problème (Module téléchargé avec succès) mais le module n'y est pas !?

• pas de message d'erreur dans les logs (apache & PHP)
• pas de fichiers (répertoire tgg*) dans le répertoire modules

Serveur sous gentoo linux : PHP 5.4.8, Apache 2.2.24 (worker) & mod_fastcgi

Merci pour ton travail, n'hésite pas à revenir vers moi si besoin de + d'information ou tests.

cheers!
agp

Hello,

I saw a gap in transaction ID when cancelling a payment.

Here are detailled actions I did to get the bugg

• ask to pay by credit card
• click on a credit card to make the scellius page appearing. On this page I noticed the transaction ID.
• cancel the payment and go back to the shop
• ask for another payment mode
• click again on a credit card. On scellius page I can see that transaction ID increaded.
• cancel again the payment and go back to the shop. In the shop, I see that the transaction ID is the first one.

Could you fix the problem when you'll have time ? Thank you.

Regards,

Hello,
We are using your module with LCL, but when the payment it's not validate by the bank customer return to our website and try again to pay, the transaction id stay the same.

The LCL don't accept same paiement_id on day.

"Transaction déjà traitée (votre paiement n'a pas été accepté)
Nous regrettons de ne pouvoir donner suite à votre demande, merci de prendre contact directement avec le commerçant afin de terminer votre commande"

To solve this issue the customer needs to clear the browser cache.

Do you have solution ?

BR
Nicolas

Bonjour,

(J'écris en français... :) )

Je viens de trouver ton module, ayant un epayment à mettre en place pour un client, sur un PS 1.6.0.6.

J'ai installé ton module (par upload FTP, car via l'interface PS admin, le module n'apparaît pas du tout.. j'ai pas checké en détails mais il n'avait pas l'air d'avoir été téléchargé par PS)

Récup du certificat de production (pas d'infos sur un certif de démo...) auprès de la banque du client.

Configuration OK, test du paiement sur un produit à 1€.

Dès que je valide la commande (après avoir choisi "Payer par carte"), j'ai le message suivant :

Paiement par carte
Paiement par carte Vous avez choisi de payer par carte.
La transaction s'effectuera sur un serveur bancaire sécurisé où les informations nécessaires vous seront demandées.
A n'importe quel moment vous pourrez revenir au choix des moyens de paiement sur notre boutique en cliquant sur le bouton d'annulation depuis le serveur bancaire.
Total à payer : 1,00 €

Le paiement par carte est indisponible jusqu'à demain.

Est-ce qu'il faut que je m'affole car cela ne fonctionne pas, ou est-ce un message retourné par la banque en elle-même ?
Je n'ai pas trouvé cette phrase dans les fichiers PHP du module, donc je me dis que c'est une erreur externe et non propre au module mais je voulais juste en avoir l'assurance. Est-ce la plateforme ATOS ?

Infos : Banque : mercanet (BNP)
PS 1.6.0.6 (fresh install)
PHP 5.3
Module tggatos : 3.3.1 (RC).

Merci encore, et quand tout sera OK (mise en production, etc), je n'hésiterai pas à faire un don pour ce super boulot !

Bonjour, certaines commandes sont doublées après réception du paiement : 2 commandes identiques sont insérées à la même seconde. Avez-vous déjà eu le soucis ? une idée pour le corriger ?

Bonjour,

Sur prestashop 1.5.6.1 module version 3.4.0
Cela fonctionne bien en décimale, mais lorsque l'on désactive, je me retrouve avec un montant divisé par 100...

Quel est le problème ? Comment résoudre ?

Maybe it's a misconfiguration here but in Prestashop 1.5 you can register the payments linked to the orders.

It needs the date, the means of payment, the transaction ID and the amount. I wondered if it would be possible to automatically register a card payment as we have all those informations.

Bonjour,

Les transaction avec ATOS fonctionne bien mais il doit y avoir un problème sur la confirmation de paiement.

Les commandes s'intègrent mais l'Etat est vide (il devrait avoir "Paiement accepté").

Et lorsque les clients reviennent sur la boutique, ils ont le message d'erreur suivant :

Voici le log atos d'une commande :

Voici les log apache correspondants :

Merci d'avance pour votre aide.

Cordialement.

Rémi

The TggAtos class in tggatos.php only calls its constructor when receiving the automatic response from the ATOS server (pat-sips-vdm.sips-atos.com). Nothing happens after that. Consequence, the order is not processed.

The ATOS server POST request is passed correctly to tggatos.php, but something is missing to trigger the dispatching, I guess. I was able to fix this issue with this hack :

// modules/tggatos/tggatos.php
class TggAtos extends PaymentModule 
{
...
public function __construct() 
{
    ...
    if (strpos($_SERVER['REQUEST_URI'],'/module/tggatos/silentresponse') !== false) 
    {
        $message = Tools::getValue('DATA');
        if (empty($message))
        {
            header(null, null, 500);
            exit;
        }
        $response = $this->uncypherResponse($message, TggAtosModuleResponseObject::TYPE_SILENT);
        $this->processResponse($response);
    }

Also, this is a bit more tricky cause a direct POST via CURL will not display this behavior:

curl -d "DATA=2020333535603028502c23........" https://test.com/fr/module/tggatos/silentresponse -v

/modules/tggatos/controllers/front/silentresponse.php is correctly called after tggatos.php.

Info:

Pshop 1.5.3.1
Module 3.0 latest GitHub commit
Demonstration mode.
"Force user return from bank" is not checked.
Debian Linux 6.0.6
PHP Version 5.3.3-7+squeeze15
Apache 2.2

Hi,

great work, it works very well, but I need to ask - is there an easy method to add new methods, i.e. Sprint Secure Solution or 3XWEB from Franfinance?

Thank you in advance for response :)

When a PAYMENT_N request is accepted, SIPS servers do automatically create future transactions for payments which will be issued automatically. These transactions consume the same transaction_id as the initial payment, but for futur dates.

When I'm in the Module Tab.
I make a search with the word 'tgg' in the form, your module have no icon

The solution is to create a logo.gif near of your picture logo.png

I'm happy to help you with this simple request :)

Line 1334 of tggatos.php, the description should read Upper right logo.

I've just learnt about Sogénactif servers (Société Générale) being using UTC time zone (undocumented), I don't know if other banks use the very same timezone (probably), so I'll add the opportunity to configure the timezone (not just force it to UTC).

THIS COULD LEAD TO transaction_id DUPLICATION OVER A DAY ON SERVERS USING OTHER TIMEZONE

Any information about other banks are appreciated.

Version PS 1.6.1.3
Version TggAtos : 4.0
Version PHP : 5.6.4-4ubuntu6.3
Système : Linux 330345-php56 4.2.0-253 #1 SMP Mon Sep 21 10:35:56 UTC 2015 armv7l
Serveur http : NC

Bonjour,

Je suis vraiment perdu et ne trouve aucune solution à mon problème.

Voilà, toute la configuration du module est OK mais le mode DEMO ne fonctionne pas ni aucun test en préprod.
Je me retrouve toujours avec le fameux : » Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient. »

Il apparait que toutes les erreurs dans la liste :
Author
TrogloGeek

1. An error log file exists, please read file /var/www/monsite.com/www/logatos/error.log and archive it to stop seeing this warning.
2. You are still in demonstration mode.

J’ai également, le 3. et le 4. qui apparaissent mais qui n’ont rien à côté.

Je pense donc très probablement que cela est issu des Binaries, mais ne sais pas comment le résoudre.
Concernant le log j’ai ca

severity 4/var/www/monsite.com/www/modules/tggatos/tggatos.php(738): Error when calling request ATOS binary, exit code was: 2 debug object: TggAtosModuleSystemCall Object ( [command] => /var/www/monsite.com/www/modules/tggatos/bin/request ‘language=fr’ ‘merchant_id=014022286611111′ ‘currency_code=978′ ‘amount=386′ ‘pathfile=/var/www/monsite.com/www/param/pathfile’ ‘normal_return_url=http://monsite.com/modules/tggatos/autodispatch/userreturn.pub.php’ ‘cancel_return_url=http://monsite.com/modules/tggatos/autodispatch/userreturn.pub.php’ ‘automatic_response_url=http://monsite.com/module/tggatos/silentresponse’ ‘customer_ip_address=82.66.59.155′ ‘customer_email=[email protected]’ ‘transaction_id=8′ ‘payment_means=CB,3,VISA,3,MASTERCARD,3′ ‘capture_mode=AUTHOR_CAPTURE’ ‘capture_day=0′ ‘customer_id=2′ ‘order_id=22′ [output] => Array ( ) [exit_code] => 2 [last_line] =>

Je ne sais vraiment plus quoi faire .
J’ai tout essayé en vain.

Je précise que mon hébergeur indique : « Je vous confirme que l’éxecution est possible toutefois, il faudra voir avec ATOS pour un système linux 64bit pour une architecture ARM, ce dernier point est important « .

Je ne sais pas du tout si les fichiers fournis par la banque sont compatibles.
Voici le nom du dossier Banque : webaffaires_617_PLUGIN_linux64-2.6.18

Je vous remercie infiniment de l’aide que vous pourrez m’apporter.

Très Cordialement,

Olivier

Thanks to @BraveKenny, while addressing the issue #19 I spotted another anomaly in N times payment mode.
When currency have decimals, without a bugfix you should expect the first payment to be ( total / N / 100 ) instead of ( total / N ).
Also, the same lack of padding with zeros to INITIAL_AMOUNT parameter.

Let's hail @BraveKenny !

Hi,

I've installed and configured the module with the option FORCE RETURN TO BANK activated, for the google analytics treatment.

It works good with the demo certificate of Mercanet 082584341411111, i can pass an order and then it redirects me to the shop and the status of the commande si updated as "Payment OK".
But when I pass the the module in Production mode, the status of the commande is not updated after the order but the payment is ok in the bank paiements logs.

I have asked Mercanet about this issue, but they don't know where is the problem. They suggest me to verify the IP adresses which are accepted but I don't have any IP restriction on my website.

This is a problem because the order is not updated and the client has to check in the bank logs if it has passed or not. And the google analytics is not updated because of that.

Have you an idea where is the problem ?

Thank you,

Hi,
I use a FR version of Presta but the module admin is in english !
Any idea ?
(the module folder is "tggatos")

Laurent

Module is set up alright, the form appears when selecting the atos module, when clicking on a card the payment page, located on the bank server, appears with the right amount.

But if I cancel the payment the following message appears :

Array ( [received fields] => Array ( [0] => 04XXXXXXXXXXXXX [1] => fr [2] => 7470 [3] => 3 [4] => CB [5] => 20130225165648 [6] => [7] => [8] => 17 [9] => [10] => [11] => 978 [12] => [13] => [14] => [15] => [16] => [17] => [18] => [19] => [20] => [21] => fr [22] => fr [23] => 2 [24] => 195038 [25] => [26] => 89.157.12.18 [27] => [28] => [29] => [30] => 02 [31] => [32] => [33] => [34] => [35] => [36] => [37] => [38] => [39] => [40] => [41] => ) [known fields] => Array ( [0] => merchant_id [1] => merchant_country [2] => amount [3] => transaction_id [4] => payment_means [5] => transmission_date [6] => payment_time [7] => payment_date [8] => response_code [9] => payment_certificate [10] => authorisation_id [11] => currency_code [12] => card_number [13] => cvv_flag [14] => cvv_response_code [15] => bank_response_code [16] => complementary_code [17] => complementary_info [18] => return_context [19] => caddie [20] => receipt_complement [21] => merchant_language [22] => language [23] => customer_id [24] => order_id [25] => customer_email [26] => customer_ip_address [27] => capture_day [28] => capture_mode [29] => data ) )

I did not have time to reproduce this in an environment running xdebug yet.

Hello,

I just added the "multistore" functionality on my preprod environment and since then, when I go to the bank payment page, I have an error "Erreur interne du serveur de paiement". Do you know if this is linked to the multistore feature ? Do we need to modify something for it to work ?
Thank you

Hello Damien,

I tryed paiment in 2 and 3 time with the version 3.1 but the bank return the following message: error check n_time_payment data (NB_PAYMENT=3;PERIOD=30;INITIAL_AMOUNT=3229660)
INITIAL_AMOUNT too big (3229660/94990)

In tggatos.php i commented $initialAmount *= 100; to solve the problem

BR
Nicolas

Hello,

I just realized that when the payment does not work, (example: 3 false card info), we are still redirected to the "order confirmation" page with this message:

Your order has been recorded.
We will process your order as soon as possible.

Any idea ?

Thank you.

class TggAtos 
...
public static function error
...
$errorlog = $error.(is_null($object) ? '' : PHP_EOL.'debug object: '.print_r($object));
Logger::addLog($errorlog);

If I'm not wrong, print_r without a second (true) parameter will leak the 'debug object' to the user screen and that's not something we want.

I tried with print_r($object, true) but this will generate a PrestaShop exception in the Logger validation method. This method (isMessage in Validate.php) requires that :

public static function isMessage($message)
{
    return !preg_match('/[<>{}]/i', $message);
}

So I ended up doing :

$debug_object = htmlentities(print_r($object,true),ENT_QUOTES,"UTF-8");
$errorlog = $error.(is_null($object) ? '' : PHP_EOL.'debug object: '. (Validate::isMessage($debug_object) ? $debug_object : 'Can\'t dump debug object to log.'));

I filter the debug object with htmlentities and I check that the debug object is valid before submitting it to the logger.

When trying to translate the module, it took me some time to find the right group to translate because the name of the group did not include "tggatos".

Currently the translations are referenced under the exact name of the view : payment_failure, payment_redirect_to_bank, param_receipt_complement, payment, payment_return

But these views already exist as they are very generic, for instance the "payment_return" view is used 6 times (with my installation) which makes it hard to find the right translation.

These views shoud be prefixed with "tggatos_" if possible, making it easier to locate and translate the module in other languages.

When using suhosin default .get.max_value_length and the NO_RESPONSE_PAGE option, the order won't be processed and the user will be redirected to the history page.

We can either alert the webmaster in the backoffice that .get.max_value_length is too low or we can bypass suhosin all together with this fix :

// modules/tggatos/controllers/front/userreturn.php
$message = Tools::getValue('DATA');
// Suhosin maximum length for GET requests (suhosin.get.max_value_length) is 512 long by default, this is too 
// small for ATOS response (1000 or more), so the response will be empty
// "We can bypass suhosin by re-building the $_GET", see http://stackoverflow.com/questions/12718609/how-to-override-suhosin-max-value for reference.
if (empty($message) && (ini_get('suhosin.get.max_value_length') == '512'))
{
    $_GET = array();
    $params = explode('&', $_SERVER['QUERY_STRING']);
    foreach ($params as $pair) {
        list($key, $value) = explode('=', $pair);
        $_GET[urldecode($key)] = urldecode($value);
    }
    $message = Tools::getValue('DATA');
}

In the BO, in the customer messages the logs from the atos transaction are listed for each order.
How can I not display them in the order tabs and in the notification by mail ? Thanks

Dear developers,

We have external applications (SAGE) that automatically request status change from a module.

In some case, this leads to Module::getInstanceByName($order->module); being called from changeIdOrderState. At end TggAtos construct is called and get to:

        if ($this->context->employee instanceof Employee
                && $this->context->employee->isLoggedBack()
                && ($this->context->controller instanceof AdminModulesController)
                && !in_array($this->name, explode('|', Tools::getValue('configure', ''))))
        {
            $this->autoCheck();
        }

where isLoggedBack looks for password in the cookie...

But our scripts are launched through curl style mechanisms, leading to having no password as we have no cookie.

Could you consider, this code in next version:

        if ($this->context->employee instanceof Employee
                && ($this->context->controller instanceof AdminModulesController)
                && $this->context->employee->isLoggedBack()
                && !in_array($this->name, explode('|', Tools::getValue('configure', ''))))
        {
            $this->autoCheck();
        }

Or even put all the employee tests at the end.

Best regards, EG

Hello,
I had a small problem with your module: in the transaction list on my bank page, the transaction id is good , but the "order number" is not and I saw in your code that you use the cart id for the "order_id" parameter.
Would it be possible to use the order id ?
Thank you

Bonjour,

sur les commandes payées grâce votre module (et sur aucune des commandes payées avec le module paypal) certaines anciennes commandes sont regénérées dans google analytics avec une quantité a 0, ce qui pose des problèmes car le CA dans google analytics n'est plus du tout bon.
Avez-vous une idée si ce problème peut venir de notre module ?

Merci beaucoup
Cordialement,
Agnès

Bonjour,

Nous utilisons votre super module, mais après avoir essayé d'optimiser notre site dans le .HTACCESS , avec les lignes ci dessous (mise en cache et compression), le transaction ID semble lui aussi mis en cache et ne s’incrémente plus. Ce qui rend le module de paiement CB inutilisable.

Si vous avez une solution je suis preneur.

# ACTIVATION DE LA COMPRESSION DES PAGES
# <IfModule mod_deflate.c>
# SetOutputFilter DEFLATE
# AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript application/x-httpd-php
# POUR LES NAVIGATEURS INCOMPATIBLES
# BrowserMatch ^Mozilla/4 gzip-only-text/html
# BrowserMatch ^Mozilla/4\.0[678] no-gzip
# BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
#PAS DE COMPRESSION POUR LES FORMATS NE LE NECESSITANT PAS
# SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
# </IfModule>

# GESTION DES DATES D'EXPIRATION POUR FAVORISER LE CACHE NAVIGATEUR
# <IfModule mod_expires.c>
#  ExpiresActive On
#  ExpiresDefault "access plus 7200 seconds"
#  ExpiresByType image/jpg "access plus 2592000 seconds"
#  ExpiresByType image/jpeg "access plus 2592000 seconds"
#  ExpiresByType image/png "access plus 2592000 seconds"
#  ExpiresByType image/gif "access plus 2592000 seconds"
#  AddType image/x-icon .ico
# ExpiresByType image/ico "access plus 2592000 seconds"
#  ExpiresByType image/icon "access plus 2592000 seconds"
#  ExpiresByType image/x-icon "access plus 2592000 seconds"
#  ExpiresByType text/css "access plus 2592000 seconds"
#  ExpiresByType text/javascript "access plus 2592000 seconds"
#  ExpiresByType text/html "access plus 7200 seconds"
#  ExpiresByType application/xhtml+xml "access plus 7200 seconds"
#  ExpiresByType application/javascript A259200
#  ExpiresByType application/x-javascript "access plus 2592000 seconds"
#  ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"


# MISE EN CACHE DES FICHIERS NON DYNAMIQUES : IMAGES, CSS, JAVASCRIPT...
# <IfModule mod_headers.c>
#  <FilesMatch "\\.(ico|jpe?g|JPE?G|png|gif|swf|css|gz)$">
#  Header set Cache-Control "max-age=2592000, public"
#  </FilesMatch>
#  <FilesMatch "\\.(js)$">
#  Header set Cache-Control "max-age=2592000, private"
#  </FilesMatch>
# <filesMatch "\\.(html|htm)$">
# Header set Cache-Control "max-age=7200, public"
# </filesMatch>

# DESACTIVATION DU CACHE POUR LES FICHIERS DYNAMIQUES
# <FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
# Header unset Cache-Control
# </FilesMatch>
# </IfModule>

# SUPPRESSION DES ETAGS
# Header unset ETag
# FileETag none

Hello all,

When payment failure, the amount showed comes from parameter of request and thus is multiplied by 100 (916€ instead of 9,16€ for instance).

If you do not want to afraid customers, it is better to modify views/templates/front/payment_failure.tpl file.
You have to change line 65 from {$tggatos_response->amount} to {$tggatos_response->amount/100}
That is no really clean but it works.

Regards,

Probably nothing to do with tggatos but is anyone else getting this return response since a day or two? I thought it may be connected to enabling 3X payment this week but no (merci Damien).

Of course ATOS is useless for sending pre-warning emails for critical changes, unlike PayPal (e.g. for SHA256, TLS1.2, etc) but there was some message in the merchant portal that is now gone.

In my case, I have 3 sites on a single server, only one of which has this problem. The problem is for all ATOS payments, it is the only site that has tggatos 3X enabled but even disabling 3X doesn't change the problem.

• the payment is correctly registered in the ATOS portal
• return is Waiting for bank validation
• no order created

Bonjour,

je viens d'installer en mode test tgg_atos.
Je l'ai installé en local et sur un serveur distant.
Sur le serveur distant, à cause de la limitation à 52 caractères, il a fallut remonter le répertoire param à la racine, et l'installation se faisant mal, il a fallut que j'intervienne manuellement pour valider le tout.

Les transactions se font bien dans les deux cas.

Par contre, sur le serveur distant, si un client fait partis d'un groupe avec une remise (distributeur), l'envoi du montant au serveur bancaire est juste (remisé), l'accord de la banque est juste, sauf que la validation de la commande se fait avec un montant non remisé et un règlement remisé (donc écart et erreur de paiement affiché).

Le plus bizarre, c'est que cela ne se produit pas en local (montant remisé pris en compte pour la commande et son règlement CB).

D'où peut venir le problème?

Cordialement

prestashop 1.2.5
tgg_atos 2.0 b3-TC3

Bonjour,

Pour ceux qui veulent la traduction du module en test en Français :

http://tinyurl.com/aghbhlv

Antoine

Bonjour, nous avons un soucis sur notre site, lorsque le paiement s'effectue, ça part vers la plateforme wordline, puis au retour, la commande se valide mais les frais de livraison ne sont plus présents. Du coup, toutes les commandes et les factures sont faussés. Avez-vous déjà eut ce problème ?

Version module : Carte bancaire avec SIPS/ATOS v4.0.0 - par TrogloGeek
Version Prestashop : 1.6.1.2

Hi,

since I have added a cart rule to my shop, invoices paid using your module tggAtos go wild :
1/ In the invoice, discount appears in products table, but not in totals, where there is no "Discount Totals" line. So the invoice total is wrong (no discount).
2/ 2 payments are created in the database : 1 with the correct reduced amount, 1 with the content of the discount (!!!). Fortunately, the payment is OK : only the first payment is actually really done by the client. But where does this second payment log comes from ??
3/ In the database, I see the order

I would like to add that :
3/ Everything works well without the cart rule
4/ The invoices generated after Paypal payment are OK : discount is taken into account, invoice total is ok in the PDF and the database, only one payment appears in B.O.

My guess : maybe some variables regarding discounts have been updated in PS 1.6.1.1 and your module doesn't use them.

Bonjour,
je sais que vous parlez français, je vais donc traduire ce qu'il y a ci-dessus pour être sûr d'être compris (mon anglais est un peu approximatif). Déjà, bravo pour ce module complexe. Une fois mis en place correctement, il fonctionne très bien.
Le problème évoqué plus haut est arrivé lors de l'introduction d'une règle dans le panier (50% sur une catégorie de produits). Celle-ci est correctement comprise par le système, et je dirais même que lors du paiement, aucun défaut n'est visible en F.O. : le montant à payer prend bien en compte la réduction.

En revanche, la facture générée est fausse :

• pas de ligne "Discount Totals" dans le bloc des totaux, donc la facture affiche un total sans réduction. Un client nous a appelé en croyant à une arnaque (!).
• Et il apparait 2 paiements : un du montant réduit (qui apparait dans le log ATOS), un second du montant de la réduction, qui lui n'apparait pas dans le fichier de log (et heureusement !).

Après étude de la BDD, je trouve ces anomalies :

• aucun numéro de CB pour ces 2 paiements, alors que les paiements des commandes sans réduction sont OK. Plus précisément : rien dans "card_number, ni "card_brand" de la table xxxx_order_payment, et pas de transaction_id pour le 2ème paiement.
• les montants "total_paid", "total_paid_incl_tax" de la table xxxx_orders ne prennent pas en compte la réduction ! En fait, aucun total dans les tables order et invoice n'ont pris en compte la réduction, il faut retrouver le payment # 1 de la facture pour retrouver le montant réellement payé, il ne s'affiche nulle part ailleurs.

À permière vue, je me serais penché sur un problème de Prestashop, mais les factures générées après un paiement par PayPal sont parfaites : prise en compte de la réduction partout, que ce soit dans le bloc des totaux dans la facture, ou dans les tables de la BDD...

Mon hypothèse est que de nouvelles variables concernant les réductions ont pu être introduites avec la version 1.6.1, et que votre module ne les prend pas correctement en compte. Ce qui m'inquiète surtout est la création systématique de ce 2ème paiement, qui est du montant de la réduction (comme si la variable du montant, au lieu de servir au calcul du total_paid, était utilisée pour créer un second paiement ??).
Je vous remonte ce bug dans l'espoir que vous y compreniez quelque chose... Et que vous puissiez garder votre module fonctionnel.
Je suis prêt à répondre rapidement à vos questions ou pour des tests, car la réduction ne peut pas être mise en œuvre en l'état sur mon site.

-Mato
(en pj vous trouverez 2 factures anonymisées qui montrent bien le problème : 1 payée avec votre module, une en utilisant le module Paypal officiel)


Conditions :

• PS 1.6.1.1, tggatos 3.4
• php 5.4 et Mysql 5.5
• pas d'overrides
• "free shipping" activé à partir de 40 €.

because of this Uncaught TypeError: Object [object Object] has no method 'tooltip'

Uncaught TypeError: Object [object Object] has no method 'tooltip'

    $('#tggatosconfigtabs').tabs({ active: 0 });
        });
</script>

then it brokes the layout and some functionnalities, any idea how to fix it
this is jquery ... and i 'm not comfortable with this; i figure this is just how to write quotes or something like this

Hi,

I can't say if it's an issue, it's just maybe an error in our configuration.
When the "Force user return from bank" checkbox is checked, and when I pay, I'm automatically redirected to the order-history page, and the order is not confirm (the cart is still full & no new order in the backoffice).
If the "Force user return from bank" checkbox is NOT checked, everything works like a charme (but I have to click on "return to the shop" button in the bank summary page to confirm the order).

So, am I missing something ?

I've activated the Debug and in the "Request sent to the Payment Server" section I've the following info :
RETURN_URL (http://www.mydomain.com/modules/tggatos/autodispatch/userreturn.pub.php)
CANCEL_URL (http://www.mydomain.com/modules/tggatos/autodispatch/userreturn.pub.php)
AUTO_RESPONSE_URL (http://www.mydomain.com/module/tggatos/silentresponse)

I also don't have any error in the apache logs.

Any idea ?

Thanks a lot !

Hi,

Thanks for a very useful module, which is almost perfect. I tried to implement it, however I came up with a problem when I put 1% fee relative to cart amount (I'm using single payment only). The fee is calculated and added correctly, however when the bank returns to the shop after successful payment, PrestaShop still sends the shopper a "payment failed" email as the total amount paid, after recalculation by the module (i.e. removal of fee applied before going to payment) is out by 1 or 2 cents.

I believe this may be caused by the rounding utilities or the way the amount of the fee, deducted from the order amount, is all re-calculated. I tried all the various rounding options in PrestaShop, but none of them seemed to fix the problem.

I would also make an improvement suggestion for the module: the ability to make the fees for the transaction (which are extremely useful) added to the order, so they are visible to the shopper on the invoice, and that admins can see how much is being collected in fees.

Thanks again for your work and efforts in putting together this module!

PS: Versions info for environment on which the above problem occurred:

• PrestaShop: 1.6.1.4
• TggAtos Module: RC_4.0.0
• PHP: 5.5.30

When I unziped the Elysnet API I received this day, the only certificate demo files I can find inside are the PHP.
After installing and configuring server, Prestashop met an error missing file when calling certif.fr.01410245031111X file.

Suggestion : Add a checkbox in BO to add or not "F_CTYPE!php!" in PATHFILE generation

Bonjour,

J'utilise un prestashop 1.5.6.2 avec la dernière version du module. Le probleme est sur la page de paiement lorsque je valide ou que j'annule le paiement le retour se fait sur une erreur 500 sur le lien suivant http://mon_site.com/modules/tggatos/autodispatch/userreturn.pub.php
Je suis sur un mutualisé OVH si des fois ca peut expliquer le problème.

Merci

First of all, many thanks for this lovely module.

Apparently, there is a case missing in this module which generates an atos error: when the amount of the payment is inferior to 1€, tggatos does indeed multiply it by 100, but according to documentation, it should also append zeros behind the number in order to make it three digits long at least.

So right now, when I pay 0.95€, I get "invalid amount length (95)"

I wish I could provide a solution as well, but I have yet to find the place in the code where the price is expressed as a string and not as an int.

It seems that in the "payment.tpl" in the "view => template => hook" folder the img should be inserted inside the link. Doing otherwise produces a result inconsistent with other payment modules :

Hi there,

Juste pour signaler un petit souci lorsque l'on désactive les décimales sur sa boutique avec l'option "Localisation>Devise". Le montant du panier n'est plus multiplié par 100 pour la transaction avec Atos.
Du coup, on se trouve avec un montant à payer / 100.

Dans tggatos.php, j'ai désactivé la condition qui vérifie si notre monnaie contient des décimales car à priori on doit quand même faire l'opération pour avoir un montant * 100.

ligne 588 :
if ($currency->decimals) $atosAmount *= 100;

devient
$atosAmount *= 100;

Idem pour ligne 631, 641, et 876 (en veillant bien à conserver le nom de la variable).

Damien, une raison particulière pour ce test ?

Et bravo pour le module, il fonctionne au top une fois ce petit souci réglé.

J'utilise le service ScelliusNet de la Banque Postale. Ce service fonctionne déjà depuis plusieurs années sur un autre site.
En passant le module en mode Production, lorsqu'on clique sur le logo du paiement par carte, le site continue à rediriger vers le mode démo :
CALL URL
https://scellius.lapostefinance.fr/cgis-payment-scellius/demo/callpayment
Comment résoudre ce problème ?

Bonjour,

Je mets en place une boutique Prestashop 1.6, votre module tggatos 3.4.0 fonctionne bien en phase de développement.
J'attaque la phase de mise en production de la boutique et dans ce cadre, j'active toutes les optimisations ainsi que la ré-écriture d'URL pour avoir les URL dites simplifiées, lors du règlement d'une commande, au clic sur le mode de paiement par carte bancaire (via votre module tggatos), j'arrive sur une page d'erreur 403 m'indiquant une interdiction d'accès.
Après investigation, il s'avère que le fichier .htaccess dans le dossier racine de votre module en est directement responsable, puisqu'en le supprimant, le fonctionnement normal est rétabli.
Je ne suis pas spécialiste en écriture de règle des fichiers .htaccess mais je devine qu'il interdit tout accès sauf aux fichiers logo.png, logo.gif et *.pub.php.
Je dispose d'autres modules de paiement qui n'ont pas de ficheir .htaccess dans leur dossier racine et qui ne présente pas cette erreur.
Que faudrait-il ajouter dans ce fichier pour qu'il ne soit pas bloquant lorsque les URL simplifiées de la boutique sont activées ?

Merci d'avance pour votre aide.
Cordialement

Hi

The table ps_tggatos_transactions_today can't be change to InnoDB as other tables.
It's because of Incremental Field, which has to be Primary key

And primary key is date + transaction_id

Hello

I'm using Sogenactif and rC 3.40 on Prestashop 1.6.0.8.
When I disable "Force user return from bank" whis is related to data[NO_RESPONSE_PAGE], there is NO record in any step until I click on "return to the merchant site" button.

It means : if the visitor closes the windows on the Sogenactif website, nothing is written in the website, no state of the command is done.

How can I help you, I could give you access to logs and tests.

regards

Due to single transaction mode captude_day being set as autofeed parameter.